Re: Overall bitrot, package reviews and fast(er) unmaintained package removals

[Felipe Sateler <fsateler@debian.org>]

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