Re: Making Debian ports less burdensome

[Steven Chamberlain <steven@pyro.eu.org>]

Hi,

Bas Wijnen:
> Removing the package from the breaking port is an option, and it
> should be easy to trigger, but it should not be automatic.  If we make
> the process easy and the maintainer doesn't do it (and also doesn't
> fix the bug), I think it is reasonable to auto-remove the package from
> testing altogether (as we currently do).

I think the testing autoremoval thing started out the same way, it
merely reported long-standing RC bugs, but removal was manual in the
beginning.

Okay, perhaps I should start working on:

  * A report of out-of-date packages in sid, for each arch;  ideally
    try to correlate those with FTBFS bugs, and highlight where there
    isn't one already filed.  If it could generate a template bug report
    ready to send (with appropriate usertags or X-Debbugs-Cc: headers),
    that would be even better.

  * A report of FTBFS bugs that have not had activity in some time.
    (Perhaps filter out FTBFS that affect many arches like amd64/i386).

Where a bug has a patch that just hasn't been applied by the maintainer,
a porter NMU might be justified.  It would be nice to have a list of
those to show to a DD who may be able to help.

If the bug has no patch, maybe it could produce an ftpmaster RM bug
template ready for someone to send;  showing the reverse-depends too.

If it is a core package, removal isn't viable, so porters need alerting
to those.  Those bugs, and the number of FTBFS bugs generally, may be a
better metric of arch release qualification than some of the criteria
that have been used in the past.

Though to be an accurate metric, we need to enumerate all the FTBFS,
not just rely on someone having filed a bug already.

(I'm specifically referring to FTBFS on arches where the package built
in the past, and is "out-of-date" in sid.  Otherwise it's not a
release-critical issue, not blocking testing migration).

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org