Michael Jones wrote: > > > On Sun, Feb 9, 2020 at 8:07 PM Rich Freeman <[email protected] > <mailto:[email protected]>> wrote: > > You could have jumped through all the required hoops and still had > it ignored. > > > That's pretty horrible, honestly. Why isn't Gentoo doing better than that? > > Yes, yes, Gentoo is run by volunteers, so on and so forth. But it's > entirely possible (and regularly accomplished in other organizations) > to emphasise a culture that actively tries to not ignore low hanging > fruit for so long. > > > > I'm not attempting to be contradictory for the sake of being > > contradictory, but the situation is significantly more complicated > > than what you said > > Not sure how that could be. I literally said "If you do report an > issue it might or might not get fixed." I'm pretty sure that hits all > the examples you supplied, being that it was basically a tautology. > There simply are no guarantees. > > > There's what you write, and what other people try to guess as to your > meaning. Apparently you intended to mean the tautology, where I > instead thought you meant something more interesting than that. > > Honestly, this conversation is just making me less interested in > contributing to Gentoo in the future. Not only do 1-liner pull > requests that fix broken packages get rejected / not fixed for a year, > but now I'm being replied to with word-games when I try to discuss the > issues that I face as an end-user. > > > Add to that, Gentoo has *so many bugs* that your bug tracking > > software, when told to simply "Give me all of the bugs" refuses to > > actually do so. > > It generally isn't a problem unless you run queries with no filters at > all. Sure, if you literally ask it for "all of the bugs" you won't > get them. So don't ask it for all of them. I'll note that even if we > closed all the bugs you'd still get the same error unless you only > asked for OPEN bugs. :) > > And if what you want is all old bugs closed, you can just filter by > date, and then you'll get all the benefits of those bugs being > filtered as far as query response limits are concerned. > > > My issue is that the list of open bugs is one of many proxy-indicators > for other aspects of the Gentoo development process. While fixing the > list of open bugs is not directly a fix for any of the potential > underlying reasons for the various fuzzy and not clearly identified > problems, it will very slightly reduce the overall "badness" while > being trivial to implement. I imagine bugzilla already has some kind > of plugin that would accomplish this that just needs to be enabled. > > > > Why should I continue opening new bugs, (or even better, provide > > patches) when I have new problems? > > Simple. If you provide a patch or bug you're more likely to get a > response than if you don't. There are no guarantees either way. > > > That's not supported by my experiences. Anecdotes aren't data, but so > far the bug's reports and patches that I've provided get ignored, but > the issues that I just wait to get fixed for me get fixed. > > So it seems to me like I should only file bugs for things that I want > to inflict longer wait times on the rest of the community, and I > shouldn't file bugs for things I actually want fixed. > > If you know of anyone who's attempted to do some statistical modeling > of the bug fix rate in Gentoo, I would appreciate being connected to > their research so I can stop feeling like a fool for attempting to help. > > > I don't see the problem as Gentoo not knowing that there are issues > > that should be tracked. I see it as a problem of Gentoo can't engage > > with it's user community in an effective way. And I see having over > > 10,000 open bugs as one of the barriers between effective user > > engagement and what we have today. > > I don't see how open bug counts are really the problem here. > > > The amount of open bugs, directly, is not the problem. > > The problem is that you're lying to people if you keep a bug in > bugzilla open for 10+ years. > > You know it won't be worked on, they know it won't be worked on. So > just close the bug. > > > Is there ever a time cutoff, after which a bug should > automatically be closed, in your opinion? > > No. > > > Then I'm not going to continue this discussion with you. Your > perspective on this is utterly incompatible with mine. > > > > Surely if something hasn't been addressed in 20 years, it won't be? > > If nobody can bother to fix 20 year old bugs on some piece of > software, why would you be running it today, and thus why would you be > searching for bugs for it? > > > Then why is it still in the Gentoo package repository? > > If it's not in the Gentoo package repository, why is there an open bug > in bugzilla about it? > > > Chances are if anybody is maintaining the package then it will > eventually get noticed and fixed. If nobody is maintaining it then > the open bugs aren't really impeding anybody doing fixes. > > > Again, this is contrary to my experiences, and what the Gentoo bug > tracker has in it. > > > > 2. The maintainer of the package in question failed to address > > the problem, even to acknowledge the problems existence, in the > > preceding 5 years. Maybe it fell through the cracks? Maybe it's > being > > deliberately ignored? Computers can do things for us automatically, > > like remind people about things. > > The only person getting reminded is the requester. A maintainer that > is deliberately ignoring bugs will be sending bot mail to /dev/null. > If requesters start pinging devs in other ways to get their attention > about such bugs, that seems more likely to just have these devs become > more aggressive about blocking such attempts from users to > communicate. That's probably part of why so few devs are on this list > at all. :) > > > Why is that person allowed to be a maintainer for that package then? > Sounds like a pretty complete abandonment of responsibility. > > And again, if the only person being reminder is the requestor, then > it's still a high possibility that they will check to see if the bug > was fixed and they didn't realize it, discover that it has been fixed, > and then close the bug. > > I just did this process last week with another project I'm involved in > and had 5 bugs get closed as resolved with end-users reporting they > simply didn't realize the bug hadn't been closed before. > > > > So stop making it a waste of people's time? > > Nobody knows how to do that. It takes effort to fix bugs, and nobody > can make an AI that will tell you up-front whether a bug is likely to > get fixed or not before you bother to file it. > > > There's a "WONTFIX" resolution in bugzilla. If the maintainer isn't > going to fix it, and they mark the issue as WONTFIX, then I won't > waste my time waiting. I'll either find another way to do what I'm > trying to do, or i'll fix the problem myself, or simply do without. > > I completely get that the world would be a better place if more bugs > get fixed. Honestly, though, the only concrete suggestion you've > offered is to close old bugs. I'm skeptical that this would really do > much to improve quality, and the only place you'd notice the change is > in running super-broad queries like "give me all the open bugs" that > nobody doing real work would actually look at. Maybe superficially it > makes things look better if you don't know what is actually going on. > For those submitting bugs though they're just getting all these bug > closed messages without the bugs being closed. > > > I get 5-10 year old results almost every time I search for any bug > related to problems I'm experiencing. Seeing results from 10 years ago > that are still open means I don't report the issue again. But I don't > actually know that the maintainer of the package even realizes the old > bug is there. > > Now you're going to tell me if the old bug was closed automatically, > and I opened a new one, that the maintainer of the package is just as > likely to do anything about the new bug as the old bug. > > And I'm going to pre-emptively respond by saying "Then close it as > WONTFIX" so I know not to waste my time, or the "maintainers" time, > reporting it. > > I'm not suggesting rules or actions related to policing the behavior > of Gentoo Developers, because I've seen first hand in the mailing list > that the Gentoo Developers will not be amused, to put it mildly, at > that kind of suggestion. > > So my only recourse, as an end user, is to explain to you the problems > I see, and try to offer "concrete" suggestions that involve purely > technological solutions. > > Closing bug reports after 10 years isn't perfect. Honestly I'd rather > see Gentoo encourage a developer community that doesn't ignore things > for a decade. But that's not going to happen, and I'm not suggesting it. > > So instead I suggest something that can be implemented, without > changing anyone's behavior, and without requiring substantial work > from the person implementing the suggestion. > > It's not a perfect solution, but perfect is the enemy of good, after all. > > > If I'm maintaining the package foo then I'm going to ask for all the > open foo bugs, and having a few 10 year old bugs in the list is no big > deal. If the package is actively maintained chances are that somebody > will get around to closing them if they look invalid. If the package > isn't actively maintained then nobody will even look at the list > except maybe a user, and the fact that 10 year old bugs are sitting > around might be a useful clue that it isn't maintained. > > > Why is Gentoo shipping packages that aren't maintained? Isn't that > what the "last rights" emails I get from time to time are all about? > > On a side note it looks like my oldest open bug is 12 years old. I'm > actually not quite sure if it is valid - maybe I'll post a comment and > see... :) > > -- > Rich > > > As stated in the middle of this reply, your perspective on this is > completely incompatible with mine, so I won't continue this conversation. > > Nevertheless, thank you for discussing it with me >
You might want to take note of the email address for Rich. He is a developer and has a better understanding of the inner workings of Gentoo. When he posts about how things work within Gentoo, he does it with knowledge that most users don't have. The thing about Gentoo is this. There's not enough manpower to do everything that every user wants. If a user wants something that the current devs can't deliver, then that user has few options. If that user is capable of creating a patch to fix a bug, then they can do so and apply that patch locally. If that user can help with the ebuild and post patches/fixes to BGO, git or whatever then they can do that. However, it still falls to the active dev as to whether he/she applies it or not. It could be that the patch fixes one problem but creates another based on USE flags etc. The devs do tend to test fixes before putting them in the tree even if the test may be limited in scope. The other option is to wait for someone else to fix it, the bug to be fixed by the dev etc. I fall into the last category because I don't code. Even my scripts don't deserve to be called that but I don't think there is a name for my little script thingys. Ignore Rich if you want but you would be the one missing out on inside info. Dale :-) :-)
