Orphaning Candidate packages for removal due to FTBFS, implications

[Matt Domsch]

On Sun, Jan 17, 2010 at 10:46:18PM -0500, Seth Vidal wrote:
> On Sat, 16 Jan 2010, Matt Domsch wrote:
> 
> > 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?
> 
> I like the idea. I like it even more if we could make a make-target for 
> saying "I'm here, shut the hell up" so it can be done easily.
> 
> So, for Hans' situation - if he has 150 pkgs - we file a 'MAINTAINED' bug 
> on any of the pkgs which has not had any change in a full release.
> 
> that should narrow the number of bugs he has to deal with, I'd
> think.

yes, it would.  Help generating the list of (packages which have not
been rebuilt since X except by the rel-eng rebuild script) would be welcome.

I do have a concern with how bugzilla will handle mass filing 9000
bugs in one fell swoop.  Perhaps pkgdb would be a more appropriate
tool to do this in?  Just a thought.

I agree FTBFS isn't really special-case.  It only highlighted the 30
or so packages which were truly unloved for a long time (no rebuild to
f12 or f13).  My goal with FTBFS is to ensure the whole distro is
self-hosting; it has the side effect of noticing packages that prevent
this.  FESCo wasn't ready to declare the owners thereof
"non-responsive", they just wanted to prepare the distro for the
possibility of the packages being removed, which orphan status on the
specific package does do.

But note: there are 2 cases we're dealing with:
1) the owner has updated some of their packages (so, responsive to
some), but unresponsive to others (FTBFS, other longstanding
unresolved bugs)
2) the owner hasn't updated _any_ of their packages in some time, even
in presence of filed bugs (non-responsive maintainer).

It's worth distinguishing, as case 1) calls for selective orphaning of
packages (just the ones not getting the attention necessary), whereas
case 2) calls for orphaning all the owner's packages.  Ideally in case
1) the owner, being still somewhat responsive, would choose to orphan
their unloved packages themselves.

The other thing to remember is that it doesn't have to be a badge of
shame to have your packages orphaned, or for you to orphan a package
yourself.  Individual's priorities and capabilities do change over
time; we need a healthy way to gracefully let people bow out of
maintaining some or all of their packages.  And we do, I see orphan
notices with others picking them up quite often on devel at .  That's a
sign of a healthy community.

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