Orphaning Candidate packages for removal due to FTBFS, implications

[Matt Domsch]

On Sat, Jan 16, 2010 at 10:13:32AM +0100, Michael Schwendt wrote:
> It's a more fundamental problem, though. The AWOL-process is for people,
> not for packages. The people may still be active (and even known to be
> active somewhere) and not AWOL, but the packages which are assigned to
> them would still look orphaned. FTBFS is just one way to find packages
> that don't even build.
> However, if that happens, it may be much too late. Such a package may have
> been in an unmaintained desolate state for a long time already.

In general I've been running the FTBFS scripts about monthly; maybe
less so as we approach a release (nearly all packages get rebuilt,
especially if there's a mass rebuild that happens).  I think that's
frequent enough to detect FTBFS; also we're not yet proposing dropping
packages that don't rebuild in F13 yet; only those that never got
rebuilt for F12.  So the FTBFS now-orphaned packages are at 1 year old
with no real progress to speak of.


> With nobody handling the incoming bugzilla tickets. With some bug
> reports having been killed in an automated way at dist EOL. And
> worse if it turns out that packages which do build are unmaintained
> nevertheless, with the same symptoms in bugzilla and in package scm.

We could easily create a new class of bugzilla ticket, say
"MAINTAINED".  An automated process would generate such tickets,
blocking F13MAINTAINED.  The ticket would ask the maintainer to close
the ticket to remain the owner of the package.  Tickets still open
after $SOMEDELAY would be candidates for orphan or non-responsive
maintainer process.  Repeat at $SOMEINTERVAL, perhaps once per release
cycle (more would be too onerous I think).

With a slight modification, my ftbfs bugzilla script could generate
the tickets.

Thoughts?

Thanks,
Matt


-- 
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux