Gentoo Archives: gentoo-project

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

Attachments

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

Replies

Subject Author
Re: [gentoo-project] How to improve detection of unmaintained packages? Raymond Jennings <shentino@×××××.com>