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 |