1 |
On Sat, Mar 23, 2019 at 3:32 AM Michał Górny <mgorny@g.o> wrote: |
2 |
|
3 |
> Hi, |
4 |
> |
5 |
> Gentoo is still having a major problem of unmaintained packages. |
6 |
> I'm not talking about pure 'maintainer-needed' here but packages that |
7 |
> have apparent maintainers and stay under the radar for long, harming |
8 |
> users in the process. I'd like to query potential solutions as how we |
9 |
> could improve this and look for new maintainers sooner. |
10 |
> |
11 |
> |
12 |
> The current state |
13 |
> ================= |
14 |
> The definition of an unmaintained package here is a bit blurry. For our |
15 |
> needs, let's say that an unmaintained package is a package that is not |
16 |
> getting attention of any of the maintainers, whose bugs are not looked |
17 |
> at, that does not receive version bumps or simply fails to build for |
18 |
> a long time. |
19 |
> |
20 |
> This is especially the case with 'revived herds', i.e. projects that |
21 |
> were formed from old herds. Their main characteristic is that they |
22 |
> 'maintain' a large number of loosely-related packages, and their |
23 |
> developers take care of only a small subset of them. Sadly, we still |
24 |
> have people who cherish that model, and instead of taking packages they |
25 |
> care about themselves, they shove it into one of 'their' herds. |
26 |
> |
27 |
> So far we're rarely catching such cases directly. Sometimes it happens |
28 |
> when another developer tries to use the package and notices the problem, |
29 |
> then finds that it's been reported a long time ago and never received |
30 |
> any attention. |
31 |
> |
32 |
> Sometimes, after retiring a developer we notice that he had 'maintained' |
33 |
> packages that were broken for years and never received any attention. |
34 |
> There are even real cases of developers taking over broken packages just |
35 |
> to prevent them from being lastrited but without ever fixing them. |
36 |
> |
37 |
> Then, some of the packages are noticed as result of major API update |
38 |
> trackers, such as the openssl-1.1+ tracker or ncurses[tinfo] tracker. |
39 |
> Those API changes provoke build failures, and while investigating them |
40 |
> we discover that some of the software hasn't seen any upstream attention |
41 |
> since 2000 (!), not to mention maintainers that could actually patch |
42 |
> the issues. |
43 |
> |
44 |
> |
45 |
> Version bump-based inactivity? |
46 |
> ============================== |
47 |
> One of the options would be to monitor inactivity as negligence to bump |
48 |
> packages. With euscan and/or repology, we are at least able to |
49 |
> partially monitor and report new versions of software (I think someone |
50 |
> used to do that but I don't see those reports anymore). While this |
51 |
> still requires some manual processing (esp. given that repology results |
52 |
> are sometimes mistaken), it would be a step forward. |
53 |
> |
54 |
> The counterarguments for doing this is that not all version bumps are |
55 |
> meaningful to Gentoo. We'd have to at least be able to filter out |
56 |
> development releases if maintainers are not doing them. Sometimes we |
57 |
> also skip releases if they don't introduce anything meaningful to Gentoo |
58 |
> users. Finally, some developers reject new versions of software for |
59 |
> various reasons. |
60 |
> |
61 |
|
62 |
I've also considered to just use time. |
63 |
|
64 |
Many *packages* have not been touched in N time. While some software |
65 |
doesn't get updates often, even routine maintenance should require edits on |
66 |
a fairly regular basis. |
67 |
|
68 |
|
69 |
> |
70 |
> |
71 |
> Bugzilla-based inactivity? |
72 |
> ========================== |
73 |
> I've noticed something interesting in Fedora lately. They have a policy |
74 |
> that if a package build failure is reported (note: they are reporting |
75 |
> them automatically) and the maintainer does not update it from the 'NEW' |
76 |
> state, it is automatically orphaned after 8 weeks. Effectively, |
77 |
> if the maintainer does not take care (or at least pretends to) |
78 |
> of the package, it is orphaned automatically. |
79 |
> |
80 |
> I suppose we might be able to look for a similar policy in Gentoo. |
81 |
> However, there are two obvious counterarguments. Firstly, this would |
82 |
> create 'busywork' that people would be required to do in order to |
83 |
> prevent from orphaning their packages. Secondly, a fair number of |
84 |
> developers would just do this 'busywork' to every new bug just to avoid |
85 |
> the problem, rendering the measure ineffective. |
86 |
> |
87 |
|
88 |
Avoid letting the perfect be the enemy of the good here. Any metric can be |
89 |
gamed by developers; but it turns out we must choose some metric to drive |
90 |
the organization. I'm fairly sure not *all* developers will automate this |
91 |
busywork; because *some* of us want to see the number of unmaintained |
92 |
packages reduced; resulting in a net-win. |
93 |
|
94 |
|
95 |
> |
96 |
> |
97 |
> What can we actually do? |
98 |
> ======================== |
99 |
> Do you have any specific ideas how we could actually improve |
100 |
> the situation? I'm particularly looking for things we could do at least |
101 |
> semi-automatically, without having to spend tremendous effort looking |
102 |
> through thousands of unhandled bugs manually. |
103 |
> |
104 |
|
105 |
So I'd recommend avoiding a specific implementation; which means don't |
106 |
trigger off of a specific signal. |
107 |
|
108 |
Signals: |
109 |
1) euscan first; because its most accurate and plausible already |
110 |
implemented. |
111 |
2) Date-based scanning; its trivial to implement. |
112 |
|
113 |
So now for each package, we have 2 straightforward signals. When was it |
114 |
last touched, how many versions behind? |
115 |
|
116 |
Rules: |
117 |
A package is unmaintained if it: |
118 |
- Has not been touched in 5 years |
119 |
- Is behind 3 versions AND hasn't been touched in 2 years |
120 |
- Is behind 5 versions AND hasn't been touched in 1 years |
121 |
|
122 |
As we add more signals (e.g. doesn't build, or unfixed bugs) we can add |
123 |
additional rules. |
124 |
|
125 |
We could generate a QA report per package on the qa reports page. |
126 |
If there is an API for request the QA report, we could cross-link from |
127 |
p.g.o. |
128 |
|
129 |
-A |
130 |
|
131 |
|
132 |
|
133 |
> -- |
134 |
> Best regards, |
135 |
> Michał Górny |
136 |
> |
137 |
> |