On 01/17/2010 03:20 PM, Thilo Bangert wrote:
Ben de Groot<yng...@gentoo.org> said:
I think we have a bigger problem with packages that have a maintainer,
at least nominally, but said maintainer does not actually maintain the
package anymore.
full ack. i was thinking that maybe we need an 'easy-fix' team, which can
do all the easy fixes, which have been laying around for way too long and
which aparently are "easy to fix" (ie. only waiting for somebody to
commit)...
I think this is a good idea. Alternatively, perhaps if we just make a
policy that it is acceptable for a dev to touch a package and leave it
with QA problems, as long as it ends up with no more QA problems than it
started with. Of course, devs are encouraged to fix QA problems
whenever they can.
This way devs will be more willing to make small fixes that generally
improve the distro without being worried about being chewed out because
they didn't go through the package with a fine-tooth comb looking for
issues.
That will at least get poorly-maintained packages trending in the right
direction. Along with that I think we need to address the problem of
packages that list a maintainer but which aren't maintained.
Perhaps a solution would be to have some way to periodically ping
maintainers to confirm they're still looking at a package. That could
take many forms - a simple one would be to ask the maintainer to touch
the metadata.xml file or something like that (obviously the manipulation
has to be something that is noticed by CVS). On the other hand we don't
want needless churn. Then an automated process can ping maintainers if
they haven't done this, and after a delay the package would be set to
maintainer-wanted.
Actively-maintained projects would be allowed to use automation to keep
packages they track marked fresh. However, the project does then become
accountable for actually maintaining them.
This would go along with an (unwritten but already in place) policy that
anybody listed as a maintainer has to actually maintain the package,
with consequences for not doing so to some defined standard. This
standard would not be zero-bugs, but certainly anything real flagged by
repoman or a violation of a written QA policy would be expected to be
cleaned up in a timely manner.
The goal is to make the maintainer field meaningful.
Then we could figure out a policy for maintainer-wanted builds. My
feeling is that as long as they build, don't have security issues, and
don't have QA issues that genuinely get in the way of some Gentoo
initiative, they can stay around. Once any of the above ceases to be
the case they're announced on-list and then treecleaned.
The bottom line though is that we can write all the rules we want -
ultimately Gentoo needs warm bodies to fix bugs. No amount of process
will get around that. What process can do for us, however, is to
increase visibility of issues so that QA doesn't waste time hunting down
inactive devs and so that people running servers or whatever can tell if
a package is actively maintained.
