Gentoo Archives: gentoo-user

From: Dale <rdalek1967@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Number of open Bugzilla bugs (Was: Question about gentoo-sources kernel release versions)
Date: Mon, 10 Feb 2020 22:23:16
Message-Id: 0b369906-3426-11cf-e2c9-fcb5aa3512ad@gmail.com
In Reply to: Re: [gentoo-user] Number of open Bugzilla bugs (Was: Question about gentoo-sources kernel release versions) by Michael Jones
1 Michael Jones wrote:
2 >
3 >
4 > On Sun, Feb 9, 2020 at 8:07 PM Rich Freeman <rich0@g.o
5 > <mailto:rich0@g.o>> wrote:
6 >
7 > You could have jumped through all the required hoops and still had
8 > it ignored.
9 >
10 >
11 > That's pretty horrible, honestly. Why isn't Gentoo doing better than that?
12 >
13 > Yes, yes, Gentoo is run by volunteers, so on and so forth. But it's
14 > entirely possible (and regularly accomplished in other organizations)
15 > to emphasise a culture that actively tries to not ignore low hanging
16 > fruit for so long.
17 >  
18 >
19 > > I'm not attempting to be contradictory for the sake of being
20 > > contradictory, but the situation is significantly more complicated
21 > > than what you said
22 >
23 > Not sure how that could be.  I literally said "If you do report an
24 > issue it might or might not get fixed."  I'm pretty sure that hits all
25 > the examples you supplied, being that it was basically a tautology.
26 > There simply are no guarantees.
27 >
28 >
29 > There's what you write, and what other people try to guess as to your
30 > meaning. Apparently you intended to mean the tautology, where I
31 > instead thought you meant something more interesting than that.
32 >
33 > Honestly, this conversation is just making me less interested in
34 > contributing to Gentoo in the future. Not only do 1-liner pull
35 > requests that fix broken packages get rejected / not fixed for a year,
36 > but now I'm being replied to with word-games when I try to discuss the
37 > issues that I face as an end-user.
38 >
39 > > Add to that, Gentoo has *so many bugs* that your bug tracking
40 > > software, when told to simply "Give me all of the bugs" refuses to
41 > > actually do so.
42 >
43 > It generally isn't a problem unless you run queries with no filters at
44 > all.  Sure, if you literally ask it for "all of the bugs" you won't
45 > get them.  So don't ask it for all of them.  I'll note that even if we
46 > closed all the bugs you'd still get the same error unless you only
47 > asked for OPEN bugs.  :)
48 >
49 > And if what you want is all old bugs closed, you can just filter by
50 > date, and then you'll get all the benefits of those bugs being
51 > filtered as far as query response limits are concerned.
52 >
53 >
54 > My issue is that the list of open bugs is one of many proxy-indicators
55 > for other aspects of the Gentoo development process. While fixing the
56 > list of open bugs is not directly a fix for any of the potential
57 > underlying reasons for the various fuzzy and not clearly identified
58 > problems, it will very slightly reduce the overall "badness" while
59 > being trivial to implement. I imagine bugzilla already has some kind
60 > of plugin that would accomplish this that just needs to be enabled. 
61 >  
62 >
63 > > Why should I continue opening new bugs, (or even better, provide
64 > > patches) when I have new problems?
65 >
66 > Simple.  If you provide a patch or bug you're more likely to get a
67 > response than if you don't.  There are no guarantees either way.
68 >
69 >
70 > That's not supported by my experiences. Anecdotes aren't data, but so
71 > far the bug's reports and patches that I've provided get ignored, but
72 > the issues that I just wait to get fixed for me get fixed.
73 >
74 > So it seems to me like I should only file bugs for things that I want
75 > to inflict longer wait times on the rest of the community, and I
76 > shouldn't file bugs for things I actually want fixed.
77 >
78 > If you know of anyone who's attempted to do some statistical modeling
79 > of the bug fix rate in Gentoo, I would appreciate being connected to
80 > their research so I can stop feeling like a fool for attempting to help.
81 >
82 > > I don't see the problem as Gentoo not knowing that there are issues
83 > > that should be tracked. I see it as a problem of Gentoo can't engage
84 > > with it's user community in an effective way. And I see having over
85 > > 10,000 open bugs as one of the barriers between effective user
86 > > engagement and what we have today.
87 >
88 > I don't see how open bug counts are really the problem here.
89 >
90 >
91 > The amount of open bugs, directly, is not the problem.
92 >
93 > The problem is that you're lying to people if you keep a bug in
94 > bugzilla open for 10+ years.
95 >
96 > You know it won't be worked on, they know it won't be worked on. So
97 > just close the bug. 
98 >
99 > > Is there ever a time cutoff, after which a bug should
100 > automatically be closed, in your opinion?
101 >
102 > No.
103 >
104 >
105 > Then I'm not going to continue this discussion with you. Your
106 > perspective on this is utterly incompatible with mine.
107 >  
108 >
109 > > Surely if something hasn't been addressed in 20 years, it won't be?
110 >
111 > If nobody can bother to fix 20 year old bugs on some piece of
112 > software, why would you be running it today, and thus why would you be
113 > searching for bugs for it?
114 >
115 >
116 > Then why is it still in the Gentoo package repository?
117 >
118 > If it's not in the Gentoo package repository, why is there an open bug
119 > in bugzilla about it?
120 >  
121 >
122 > Chances are if anybody is maintaining the package then it will
123 > eventually get noticed and fixed.  If nobody is maintaining it then
124 > the open bugs aren't really impeding anybody doing fixes.
125 >
126 >
127 > Again, this is contrary to my experiences, and what the Gentoo bug
128 > tracker has in it.
129 >  
130 >
131 > > 2. The maintainer of the package in question failed to address
132 > > the problem, even to acknowledge the problems existence, in the
133 > > preceding 5 years. Maybe it fell through the cracks? Maybe it's
134 > being
135 > > deliberately ignored? Computers can do things for us automatically,
136 > > like remind people about things.
137 >
138 > The only person getting reminded is the requester.  A maintainer that
139 > is deliberately ignoring bugs will be sending bot mail to /dev/null.
140 > If requesters start pinging devs in other ways to get their attention
141 > about such bugs, that seems more likely to just have these devs become
142 > more aggressive about blocking such attempts from users to
143 > communicate.  That's probably part of why so few devs are on this list
144 > at all.  :)
145 >
146 >
147 > Why is that person allowed to be a maintainer for that package then?
148 > Sounds like a pretty complete abandonment of responsibility.
149 >
150 > And again, if the only person being reminder is the requestor, then
151 > it's still a high possibility that they will check to see if the bug
152 > was fixed and they didn't realize it, discover that it has been fixed,
153 > and then close the bug.
154 >
155 > I just did this process last week with another project I'm involved in
156 > and had 5 bugs get closed as resolved with end-users reporting they
157 > simply didn't realize the bug hadn't been closed before.
158 >  
159 >
160 > > So stop making it a waste of people's time?
161 >
162 > Nobody knows how to do that.  It takes effort to fix bugs, and nobody
163 > can make an AI that will tell you up-front whether a bug is likely to
164 > get fixed or not before you bother to file it.
165 >
166 >
167 > There's a "WONTFIX" resolution in bugzilla. If the maintainer isn't
168 > going to fix it, and they mark the issue as WONTFIX, then I won't
169 > waste my time waiting. I'll either find another way to do what I'm
170 > trying to do, or i'll fix the problem myself, or simply do without.
171 >
172 > I completely get that the world would be a better place if more bugs
173 > get fixed.  Honestly, though, the only concrete suggestion you've
174 > offered is to close old bugs.  I'm skeptical that this would really do
175 > much to improve quality, and the only place you'd notice the change is
176 > in running super-broad queries like "give me all the open bugs" that
177 > nobody doing real work would actually look at.  Maybe superficially it
178 > makes things look better if you don't know what is actually going on.
179 > For those submitting bugs though they're just getting all these bug
180 > closed messages without the bugs being closed.
181 >
182 >
183 > I get 5-10 year old results almost every time I search for any bug
184 > related to problems I'm experiencing. Seeing results from 10 years ago
185 > that are still open means I don't report the issue again. But I don't
186 > actually know that the maintainer of the package even realizes the old
187 > bug is there.
188 >
189 > Now you're going to tell me if the old bug was closed automatically,
190 > and I opened a new one, that the maintainer of the package is just as
191 > likely to do anything about the new bug as the old bug.
192 >
193 > And I'm going to pre-emptively respond by saying "Then close it as
194 > WONTFIX" so I know not to waste my time, or the "maintainers" time,
195 > reporting it.
196 >
197 > I'm not suggesting rules or actions related to policing the behavior
198 > of Gentoo Developers, because I've seen first hand in the mailing list
199 > that the Gentoo Developers will not be amused, to put it mildly, at
200 > that kind of suggestion.
201 >
202 > So my only recourse, as an end user, is to explain to you the problems
203 > I see, and try to offer "concrete" suggestions that involve purely
204 > technological solutions. 
205 >
206 > Closing bug reports after 10 years isn't perfect. Honestly I'd rather
207 > see Gentoo encourage a developer community that doesn't ignore things
208 > for a decade. But that's not going to happen, and I'm not suggesting it.
209 >
210 > So instead I suggest something that can be implemented, without
211 > changing anyone's behavior, and without requiring substantial work
212 > from the person implementing the suggestion. 
213 >
214 > It's not a perfect solution, but perfect is the enemy of good, after all.
215 >  
216 >
217 > If I'm maintaining the package foo then I'm going to ask for all the
218 > open foo bugs, and having a few 10 year old bugs in the list is no big
219 > deal.  If the package is actively maintained chances are that somebody
220 > will get around to closing them if they look invalid.  If the package
221 > isn't actively maintained then nobody will even look at the list
222 > except maybe a user, and the fact that 10 year old bugs are sitting
223 > around might be a useful clue that it isn't maintained.
224 >
225 >  
226 > Why is Gentoo shipping packages that aren't maintained? Isn't that
227 > what the "last rights" emails I get from time to time are all about?
228 >
229 > On a side note it looks like my oldest open bug is 12 years old.  I'm
230 > actually not quite sure if it is valid - maybe I'll post a comment and
231 > see...  :)
232 >
233 > --
234 > Rich
235 >
236 >
237 > As stated in the middle of this reply, your perspective on this is
238 > completely incompatible with mine, so I won't continue this conversation.
239 >
240 > Nevertheless, thank you for discussing it with me
241 >  
242
243
244 You might want to take note of the email address for Rich.  He is a
245 developer and has a better understanding of the inner workings of
246 Gentoo.  When he posts about how things work within Gentoo, he does it
247 with knowledge that most users don't have. 
248
249 The thing about Gentoo is this.  There's not enough manpower to do
250 everything that every user wants.  If a user wants something that the
251 current devs can't deliver, then that user has few options.  If that
252 user is capable of creating a patch to fix a bug, then they can do so
253 and apply that patch locally.  If that user can help with the ebuild and
254 post patches/fixes to BGO, git or whatever then they can do that. 
255 However, it still falls to the active dev as to whether he/she applies
256 it or not.  It could be that the patch fixes one problem but creates
257 another based on USE flags etc.  The devs do tend to test fixes before
258 putting them in the tree even if the test may be limited in scope.  The
259 other option is to wait for someone else to fix it, the bug to be fixed
260 by the dev etc.  I fall into the last category because I don't code. 
261 Even my scripts don't deserve to be called that but I don't think there
262 is a name for my little script thingys. 
263
264 Ignore Rich if you want but you would be the one missing out on inside
265 info. 
266
267 Dale
268
269 :-)  :-) 

Replies