On Wed, 06 Apr 2016 00:18:10 +0200, Ondřej Surý wrote: > Hey, > > while doing some work on PHP transitions, saving courier-imap, finally > packaging seafile since they finally stopped violating GPL, I found a > quite a lot of bitrot in some (mostly leaf) packages. Packages untouched > for years after initial upload, packages with unreachable maintainers, > etc[1]. > > I totally understand that our QA team can't solve all of this, but I > have a couple of automated ideas that might help:
This is something we really need to start thinking about. Tasks that involve more than a few packages usually require a large number of NMUs, which is quite sad. > * Some automated check that would mark the package as outdated. Outdated > packages won't make it into stable and would be removed from unstable. > Some indicators that package might be outdated: > - big difference (in time, in version numbers?) between upstream > version and Debian version > - no upload in a long time s/upload/maintainer upload/ > - some really outdated standards version > - some really outdated dh compat level > - using outdated packaging tools (and please don't go into the 1.0 vs > 3.0 fight again here :-) > - something with being a leaf library and not used by anybody else for > a long time (combine that with popcon, f.e.?) > - other indicators - Is maintained by the QA group (for longer than X time?) - Is orphaned (for longer than X time?) - Is RFA (for longer than X time? Or maybe it should auto-move to orphaned) Essentially, if nobody steps up to maintain the packages, then they should go. - Maintainer does not respond to bug reports in a timely (eg, 1.5 months calculated per package). I think that maintainer responsiveness should be the key metric, not up- to-dateness (ie, the maintainer may be holding back for good reasons, but those reasons should be explained). This should also help detecting teams that have effectively become empty. > > * Package marked as "outdated" would: > a) not be able to enter "stable" > b) not be able to enter "testing" > c) would be removed from "unstable" Adding to the testing autoremoval queue would be a great start. -- Saludos, Felipe Sateler
