From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A57CF138334 for ; Sat, 23 Mar 2019 17:38:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8C771E0973; Sat, 23 Mar 2019 17:38:46 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4166BE0971 for ; Sat, 23 Mar 2019 17:38:46 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 6F047335D27; Sat, 23 Mar 2019 17:38:44 +0000 (UTC) Message-ID: Subject: Re: [gentoo-project] How to improve detection of unmaintained packages? From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-project@lists.gentoo.org Date: Sat, 23 Mar 2019 18:38:40 +0100 In-Reply-To: References: Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-SZSpPNgtQ90MMROGCj5u" User-Agent: Evolution 3.30.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: e1592c04-76b9-4a02-a156-2b8201a29877 X-Archives-Hash: f0254c84f93a30845b6f7788f393d21b --=-SZSpPNgtQ90MMROGCj5u Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2019-03-23 at 10:05 -0700, Raymond Jennings wrote: > On Sat, Mar 23, 2019 at 7:18 AM Alec Warner wrote: >=20 > >=20 > > On Sat, Mar 23, 2019 at 3:32 AM Micha=C5=82 G=C3=B3rny wrote: > >=20 > > > Hi, > > >=20 > > > Gentoo is still having a major problem of unmaintained packages. > > > I'm not talking about pure 'maintainer-needed' here but packages that > > > have apparent maintainers and stay under the radar for long, harming > > > users in the process. I'd like to query potential solutions as how w= e > > > could improve this and look for new maintainers sooner. > > >=20 > > >=20 > > > The current state > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > The definition of an unmaintained package here is a bit blurry. For = our > > > needs, let's say that an unmaintained package is a package that is no= t > > > getting attention of any of the maintainers, whose bugs are not looke= d > > > at, that does not receive version bumps or simply fails to build for > > > a long time. > > >=20 > > > This is especially the case with 'revived herds', i.e. projects that > > > were formed from old herds. Their main characteristic is that they > > > 'maintain' a large number of loosely-related packages, and their > > > developers take care of only a small subset of them. Sadly, we still > > > have people who cherish that model, and instead of taking packages th= ey > > > care about themselves, they shove it into one of 'their' herds. > > >=20 > > > So far we're rarely catching such cases directly. Sometimes it happe= ns > > > when another developer tries to use the package and notices the probl= em, > > > then finds that it's been reported a long time ago and never received > > > any attention. > > >=20 > > > Sometimes, after retiring a developer we notice that he had 'maintain= ed' > > > packages that were broken for years and never received any attention. > > > There are even real cases of developers taking over broken packages j= ust > > > to prevent them from being lastrited but without ever fixing them. > > >=20 > > > Then, some of the packages are noticed as result of major API update > > > trackers, such as the openssl-1.1+ tracker or ncurses[tinfo] tracker. > > > Those API changes provoke build failures, and while investigating the= m > > > we discover that some of the software hasn't seen any upstream attent= ion > > > since 2000 (!), not to mention maintainers that could actually patch > > > the issues. > > >=20 > > >=20 > > > Version bump-based inactivity? > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > One of the options would be to monitor inactivity as negligence to bu= mp > > > packages. With euscan and/or repology, we are at least able to > > > partially monitor and report new versions of software (I think someon= e > > > used to do that but I don't see those reports anymore). While this > > > still requires some manual processing (esp. given that repology resul= ts > > > are sometimes mistaken), it would be a step forward. > > >=20 > > > The counterarguments for doing this is that not all version bumps are > > > meaningful to Gentoo. We'd have to at least be able to filter out > > > development releases if maintainers are not doing them. Sometimes we > > > also skip releases if they don't introduce anything meaningful to Gen= too > > > users. Finally, some developers reject new versions of software for > > > various reasons. > > >=20 > >=20 > > I've also considered to just use time. > >=20 > > Many *packages* have not been touched in N time. While some software > > doesn't get updates often, even routine maintenance should require edit= s on > > a fairly regular basis. > >=20 > >=20 > > >=20 > > > Bugzilla-based inactivity? > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > > I've noticed something interesting in Fedora lately. They have a pol= icy > > > that if a package build failure is reported (note: they are reporting > > > them automatically) and the maintainer does not update it from the 'N= EW' > > > state, it is automatically orphaned after 8 weeks. Effectively, > > > if the maintainer does not take care (or at least pretends to) > > > of the package, it is orphaned automatically. > > >=20 > > > I suppose we might be able to look for a similar policy in Gentoo. > > > However, there are two obvious counterarguments. Firstly, this would > > > create 'busywork' that people would be required to do in order to > > > prevent from orphaning their packages. Secondly, a fair number of > > > developers would just do this 'busywork' to every new bug just to avo= id > > > the problem, rendering the measure ineffective. > > >=20 > >=20 > > Avoid letting the perfect be the enemy of the good here. Any metric can= be > > gamed by developers; but it turns out we must choose some metric to dri= ve > > the organization. I'm fairly sure not *all* developers will automate th= is > > busywork; because *some* of us want to see the number of unmaintained > > packages reduced; resulting in a net-win. > >=20 > >=20 > > >=20 > > > What can we actually do? > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > Do you have any specific ideas how we could actually improve > > > the situation? I'm particularly looking for things we could do at le= ast > > > semi-automatically, without having to spend tremendous effort looking > > > through thousands of unhandled bugs manually. > > >=20 > >=20 > > So I'd recommend avoiding a specific implementation; which means don't > > trigger off of a specific signal. > >=20 > > Signals: > > 1) euscan first; because its most accurate and plausible already > > implemented. > > 2) Date-based scanning; its trivial to implement. > >=20 > > So now for each package, we have 2 straightforward signals. When was it > > last touched, how many versions behind? > >=20 > > Rules: > > A package is unmaintained if it: > > - Has not been touched in 5 years > > - Is behind 3 versions AND hasn't been touched in 2 years > > - Is behind 5 versions AND hasn't been touched in 1 years > >=20 > > As we add more signals (e.g. doesn't build, or unfixed bugs) we can add > > additional rules. > >=20 > > We could generate a QA report per package on the qa reports page. > > If there is an API for request the QA report, we could cross-link from > > p.g.o. > >=20 > > -A > >=20 > >=20 > >=20 > > > -- > > > Best regards, > > > Micha=C5=82 G=C3=B3rny > > >=20 > > >=20 > As a side observation I'd like to exempt a package from being flagged as > unmaintained if there's nothing wrong with it. If upstream is idle and t= he > package in a quiet state simply because there's no work needing done, the= n > the package should be left alone. This is the attitude that means that few months later a single person is overburdened with a few dozens unmaintained packages all suddenly falling apart. Just like ncurses[tinfo]. Or openssl-1.1. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-SZSpPNgtQ90MMROGCj5u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEXr8g+Zb7PCLMb8pAur8dX/jIEQoFAlyWbyBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDVF QkYyMEY5OTZGQjNDMjJDQzZGQ0E0MEJBQkYxRDVGRjhDODExMEEACgkQur8dX/jI EQpHoQ/+Oesz+CY4fLKmEJ0uiWLTUICHC+dYqVJGCjdVr2sJpQaUpBdtz2JzafG8 4SpEeuJ9vbeJDnYLu0AR8SdOJBCwLkvit6mT1yTTRhay7ydPETxwxdIXhOxRiHTI cCuwZ+JrWTnFo2edMoUpz+K73UfWNAwTGGUXb+gudnQvKywKGVT3TzLHC8PMf5+U c5aXZMjqL8Jj/Z+gaFAnMXYVk9wHNPJRindElqYrAaKuOu6Bx2RSWPLdoA0N/0O0 w4SYb+2gR1jEaeQirRKQoIgndw8x/YhwjSoMUlGjI/hk0pY0MOoRBA8MVIcG1eh1 Qmw58NebDd8it3UrNnTrLdgcYeTfNJVwfMPe0wsd2qiWYqkMvbPzh0RlcslAtxtW S7IN2btFhFWBFL8YHIMW8+vC/kjc/vTQFisKaAMWNge/K9H+ptMNmeI2Vr3ExNJ9 5rSvvALYucEQ/KV2LUVhln9STyT20y66a4OQfJaK0d+ijachkda68ZkN5ovT11Ep PvH1foQ2SnCYCNQRbuDDFHeagMmUSJa4tUDn19CUxD1qqL72LcHmX5Xwn2LAm+UG 6AdOKIdSBRBciChxCi3lAHnckJq6IKh0nkGK+hT1nGwTORUVD8s4pz0dQpVy4mnL fdr8uW5yL6fA7MEHPke9beaFLrLpPuKgqrxLfHPRpOXAjqTaIX8= =MlGF -----END PGP SIGNATURE----- --=-SZSpPNgtQ90MMROGCj5u--