Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: [gentoo-project] How to improve detection of unmaintained packages?
Date: Sat, 23 Mar 2019 07:32:52
Message-Id: f82282537e3a7926903f9fac9d71eb3156a4c255.camel@gentoo.org
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies