On Sat, Feb 15, 2020 at 8:39 AM Kai Peter <k...@lists.openqmail.org> wrote: > > On 2020-02-15 01:46, Rich Freeman wrote: > > On Fri, Feb 14, 2020 at 7:25 PM Marc Joliet <mar...@gmx.de> wrote: > >> > > > >> like, say, HAL: https://bugs.gentoo.org/401257. > > > > That isn't a HAL bug - it is a bug for a relatively recent version of > > pm-utils. > This is one of the issues with a general discussion of overridden > points: switch to an unimportant detail (of an example).
Actually, I only brought it up because it actually is a pretty good illustration with the problem here. It is really easy to run a query and get a bunch of results and extrapolate from there. The problem is that when you actually start looking at the results you're returning they are a lot more nuanced. I am certain that there are plenty of open bugs that are no longer valid or which were resolved upstream and so on. The problem is that it takes a fair bit of effort to actually identify these without just closing out a ton of bugs wholesale which are still valid and relevant. > I couldn't agree > with some changes in the direction Gentoo is going. It looks a bit like > swarm intelligence. That is hardly a change. Gentoo has been basically operating like a swarm intelligence for most of its existence. That was less the case in the drobbins days, but that was a long time ago. Now Gentoo is largely an amalgamation of volunteer developers working on their personal interests with some common rules and a very minimal shared set of values. It has been this way for a good 10-15 years really. It is a model that actually works pretty well for many things. Closing bugs isn't one of them, however, as: 1. Many packages were put there by somebody who was interested in them at the time and is either no longer around or is no longer interested, and these can be targets of bugs. 2. Any dev can work on whatever they want, not necessarily the stuff that most of the bugs are open for. 3. Since anybody could take up an interest in anything at any time, nobody can say with confidence that a particular bug will or won't get fixed in the next week. Maybe nobody today is interested in fixing it, but somebody new could show up tomorrow and work on it. It is a very bottom-up approach. It is basically the opposite of something like Agile where you target some MVP and everybody focuses on a narrow scope to get a bolus of work done. > Nothing personal, just IMHO. Will I get banned from this list now? Nobody gets banned from lists for having an opinion. It is pretty hard to get banned in general but it tends to happen when it starts to turn into harassment/spam or gets personal. Basically see the code of conduct. Having an opinion on something isn't really a problem. Misinformation can become a problem but it has to be pretty bad before anything is done. > > > > If an issue no longer exists then of course the bug should be closed. > Why doesn't this not happen? That goes back to the example above. To know if an issue still exists somebody needs to investigate. The reason that no developer has investigated all those ancient bugs is the same as the reason you personally haven't investigated them. There just isn't any particular individual interested in doing it. If somebody wanted to propose a bug cleanup crew project that went looking to close out old bugs with some defined rules around what they're going to do, I bet there would be support for it, as long as the rules seemed reasonable. I doubt anybody is going to get push-back for closing bugs for stuff that is no longer in the tree, or which doesn't apply to current versions in the tree, and so on. Where you'd hit controversy is stuff that probably is still valid but just has nobody interested in fixing it right now. But, IMO it is a lot of work for little reward. I think some of this is the whole "sort vs search" email workflow argument. Different people have different preferences, but for stuff that probably won't get looked at much it makes more sense to not invest a ton of effort into housekeeping. If you spent a lot of time closing out 30 out of 40 bugs for some unmaintained package, the other 10 will still sit and rot for quite a while. If the bugs were bad enough to be causing serious issues chances are the treecleaners would have already caught it. Things like security bugs aren't treated the same as "package randomly doesn't build in this 0.1% edge case with a simple workaround." -- Rich
