Gentoo Archives: gentoo-user

From: Rich Freeman <rich0@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Number of open Bugzilla bugs
Date: Sat, 15 Feb 2020 15:04:39
Message-Id: CAGfcS_n45nkWWh-M1xVxGWEJQApodWJ-dh22WykqjQagnkP-3g@mail.gmail.com
In Reply to: Re: [gentoo-user] Number of open Bugzilla bugs by Kai Peter
1 On Sat, Feb 15, 2020 at 8:39 AM Kai Peter <kp@×××××××××××××××.org> wrote:
2 >
3 > On 2020-02-15 01:46, Rich Freeman wrote:
4 > > On Fri, Feb 14, 2020 at 7:25 PM Marc Joliet <marcec@×××.de> wrote:
5 > >>
6 > >
7 > >> like, say, HAL: https://bugs.gentoo.org/401257.
8 > >
9 > > That isn't a HAL bug - it is a bug for a relatively recent version of
10 > > pm-utils.
11 > This is one of the issues with a general discussion of overridden
12 > points: switch to an unimportant detail (of an example).
13
14 Actually, I only brought it up because it actually is a pretty good
15 illustration with the problem here. It is really easy to run a query
16 and get a bunch of results and extrapolate from there.
17
18 The problem is that when you actually start looking at the results
19 you're returning they are a lot more nuanced.
20
21 I am certain that there are plenty of open bugs that are no longer
22 valid or which were resolved upstream and so on. The problem is that
23 it takes a fair bit of effort to actually identify these without just
24 closing out a ton of bugs wholesale which are still valid and
25 relevant.
26
27 > I couldn't agree
28 > with some changes in the direction Gentoo is going. It looks a bit like
29 > swarm intelligence.
30
31 That is hardly a change. Gentoo has been basically operating like a
32 swarm intelligence for most of its existence. That was less the case
33 in the drobbins days, but that was a long time ago.
34
35 Now Gentoo is largely an amalgamation of volunteer developers working
36 on their personal interests with some common rules and a very minimal
37 shared set of values. It has been this way for a good 10-15 years
38 really.
39
40 It is a model that actually works pretty well for many things.
41 Closing bugs isn't one of them, however, as:
42
43 1. Many packages were put there by somebody who was interested in
44 them at the time and is either no longer around or is no longer
45 interested, and these can be targets of bugs.
46 2. Any dev can work on whatever they want, not necessarily the stuff
47 that most of the bugs are open for.
48 3. Since anybody could take up an interest in anything at any time,
49 nobody can say with confidence that a particular bug will or won't get
50 fixed in the next week. Maybe nobody today is interested in fixing
51 it, but somebody new could show up tomorrow and work on it.
52
53 It is a very bottom-up approach. It is basically the opposite of
54 something like Agile where you target some MVP and everybody focuses
55 on a narrow scope to get a bolus of work done.
56
57 > Nothing personal, just IMHO. Will I get banned from this list now?
58
59 Nobody gets banned from lists for having an opinion. It is pretty
60 hard to get banned in general but it tends to happen when it starts to
61 turn into harassment/spam or gets personal. Basically see the code of
62 conduct. Having an opinion on something isn't really a problem.
63 Misinformation can become a problem but it has to be pretty bad before
64 anything is done.
65
66 > >
67 > > If an issue no longer exists then of course the bug should be closed.
68 > Why doesn't this not happen?
69
70 That goes back to the example above. To know if an issue still exists
71 somebody needs to investigate.
72
73 The reason that no developer has investigated all those ancient bugs
74 is the same as the reason you personally haven't investigated them.
75 There just isn't any particular individual interested in doing it.
76
77 If somebody wanted to propose a bug cleanup crew project that went
78 looking to close out old bugs with some defined rules around what
79 they're going to do, I bet there would be support for it, as long as
80 the rules seemed reasonable. I doubt anybody is going to get
81 push-back for closing bugs for stuff that is no longer in the tree, or
82 which doesn't apply to current versions in the tree, and so on. Where
83 you'd hit controversy is stuff that probably is still valid but just
84 has nobody interested in fixing it right now.
85
86 But, IMO it is a lot of work for little reward. I think some of this
87 is the whole "sort vs search" email workflow argument. Different
88 people have different preferences, but for stuff that probably won't
89 get looked at much it makes more sense to not invest a ton of effort
90 into housekeeping. If you spent a lot of time closing out 30 out of
91 40 bugs for some unmaintained package, the other 10 will still sit and
92 rot for quite a while. If the bugs were bad enough to be causing
93 serious issues chances are the treecleaners would have already caught
94 it. Things like security bugs aren't treated the same as "package
95 randomly doesn't build in this 0.1% edge case with a simple
96 workaround."
97
98 --
99 Rich