Using python-bugzilla. Follow up thread on fedora-devel.
---------- Forwarded message ----------
From: Kevin Fenzi <kevin(a)scrye.com>
Date: 2010/1/16
Subject: Re: Orphaning Candidate packages for removal due to FTBFS, implications
To: devel(a)lists.fedoraproject.org
On Sat, 16 Jan 2010 10:13:32 +0100
Michael Schwendt <mschwendt(a)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
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Rakesh Pandit
https://fedoraproject.org/wiki/User:Rakesh
freedom, friends, features, first