1 |
Hi, |
2 |
|
3 |
Gentoo is still having a major problem of unmaintained packages. |
4 |
I'm not talking about pure 'maintainer-needed' here but packages that |
5 |
have apparent maintainers and stay under the radar for long, harming |
6 |
users in the process. I'd like to query potential solutions as how we |
7 |
could improve this and look for new maintainers sooner. |
8 |
|
9 |
|
10 |
The current state |
11 |
================= |
12 |
The definition of an unmaintained package here is a bit blurry. For our |
13 |
needs, let's say that an unmaintained package is a package that is not |
14 |
getting attention of any of the maintainers, whose bugs are not looked |
15 |
at, that does not receive version bumps or simply fails to build for |
16 |
a long time. |
17 |
|
18 |
This is especially the case with 'revived herds', i.e. projects that |
19 |
were formed from old herds. Their main characteristic is that they |
20 |
'maintain' a large number of loosely-related packages, and their |
21 |
developers take care of only a small subset of them. Sadly, we still |
22 |
have people who cherish that model, and instead of taking packages they |
23 |
care about themselves, they shove it into one of 'their' herds. |
24 |
|
25 |
So far we're rarely catching such cases directly. Sometimes it happens |
26 |
when another developer tries to use the package and notices the problem, |
27 |
then finds that it's been reported a long time ago and never received |
28 |
any attention. |
29 |
|
30 |
Sometimes, after retiring a developer we notice that he had 'maintained' |
31 |
packages that were broken for years and never received any attention. |
32 |
There are even real cases of developers taking over broken packages just |
33 |
to prevent them from being lastrited but without ever fixing them. |
34 |
|
35 |
Then, some of the packages are noticed as result of major API update |
36 |
trackers, such as the openssl-1.1+ tracker or ncurses[tinfo] tracker. |
37 |
Those API changes provoke build failures, and while investigating them |
38 |
we discover that some of the software hasn't seen any upstream attention |
39 |
since 2000 (!), not to mention maintainers that could actually patch |
40 |
the issues. |
41 |
|
42 |
|
43 |
Version bump-based inactivity? |
44 |
============================== |
45 |
One of the options would be to monitor inactivity as negligence to bump |
46 |
packages. With euscan and/or repology, we are at least able to |
47 |
partially monitor and report new versions of software (I think someone |
48 |
used to do that but I don't see those reports anymore). While this |
49 |
still requires some manual processing (esp. given that repology results |
50 |
are sometimes mistaken), it would be a step forward. |
51 |
|
52 |
The counterarguments for doing this is that not all version bumps are |
53 |
meaningful to Gentoo. We'd have to at least be able to filter out |
54 |
development releases if maintainers are not doing them. Sometimes we |
55 |
also skip releases if they don't introduce anything meaningful to Gentoo |
56 |
users. Finally, some developers reject new versions of software for |
57 |
various reasons. |
58 |
|
59 |
|
60 |
Bugzilla-based inactivity? |
61 |
========================== |
62 |
I've noticed something interesting in Fedora lately. They have a policy |
63 |
that if a package build failure is reported (note: they are reporting |
64 |
them automatically) and the maintainer does not update it from the 'NEW' |
65 |
state, it is automatically orphaned after 8 weeks. Effectively, |
66 |
if the maintainer does not take care (or at least pretends to) |
67 |
of the package, it is orphaned automatically. |
68 |
|
69 |
I suppose we might be able to look for a similar policy in Gentoo. |
70 |
However, there are two obvious counterarguments. Firstly, this would |
71 |
create 'busywork' that people would be required to do in order to |
72 |
prevent from orphaning their packages. Secondly, a fair number of |
73 |
developers would just do this 'busywork' to every new bug just to avoid |
74 |
the problem, rendering the measure ineffective. |
75 |
|
76 |
|
77 |
What can we actually do? |
78 |
======================== |
79 |
Do you have any specific ideas how we could actually improve |
80 |
the situation? I'm particularly looking for things we could do at least |
81 |
semi-automatically, without having to spend tremendous effort looking |
82 |
through thousands of unhandled bugs manually. |
83 |
|
84 |
-- |
85 |
Best regards, |
86 |
Michał Górny |