Orphaning Candidate packages for removal due to FTBFS, implications

[Kevin Fenzi]

On Sat, 16 Jan 2010 10:13:32 +0100
Michael Schwendt <mschwendt at gmail.com> 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.
> 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.
> 
> Makes me wonder what bugzilla status report scripts we have? To
> create a list of potentially unmaintained packages earlier and to
> detect packages with non-responsive owners.

Yeah, there was talk a while back about setting something up to try and
detect poorly maintained/unmaintained packages, but I fear nothing ever
came of it. 

I think it would be great to have some automated script that used a
variety of input info to try and come up with a list of packages and/or
maintainers who are not responsive. Unfortunately, this will be
tricky to get right as there are a lot of corner cases: This could
include: 

- Process bugzilla. 
	Maintainers: 
	How many bugs are assigned to each maintainer. 
	How many of those have never had a comment by that maintainer. 
	How many of those are over a month old
	How many of those are over a year old
	How many of those are over 5 years old. 

	Packages: 
	Packages with the most bugs (would need to weight somehow
		things like the kernel or X, and/or abrt bugs). Perhaps
		divide by co-maintainers?
	Packages that have upstream updates that haven't been acted on.

-SCM Commits / Bodhi / Koji

	Packages: 

	Packages that have had no SCM commits in a cycle. 
	Packages that have had no updates in a cycle. 

	Maintainers: 
	Maintainers who have not commited to anything in a
		cycle
	Maintainers who have never submitted an update. 
	Maintainers who have never built anything in koji.
	Maintainers who haven't built anything in a cycle. 
	Maintainers who haven't built anything in a year. 
	
- Mail / FAS:
	Maintainers who have never posted to fedora*
	Maintainers who's fedora account system email bounces
	Maintainers who's fedora account system email is never
		responded to.
	Sponsors who have never sponsored anyone. 
	Sponsors who have not sponsored anyone in a year.
	Sponsors who have not sponsored anyone in 5 years. 

- Planet: 
	Maintainers who have a feed, but no posts. 

etc. 

You can see there is a lot of info out there, but much of it may not
apply in reality. Ie, there is a package that doesn't update because
it's quite stable. It has no bugs against it and the maintainer isn't
doing anything else in Fedora. :) 

So, it might be nice to have such a tool and have it generate a list of
possible maintainers/packages that need help. Then a human should look
over the list and try and contact maintainers/gather info on packages
and/or start unresponsive maintainer, etc. 

Any takers for writing such a script?

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100116/41359807/attachment.bin