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 |
:-) :-) |