Re: Self-assessment of the quality of the maintenance work
On Mon, 22 Dec 2008, Andreas Tille wrote:
> Do you just want to parse the list of Maintainer / Uploaders
> and leave out generic group addresses?
Yes, only real people are important and able to work. :)
> You are talking about a "passive" maintainer in the case of the Perl
> maintainers group.
No. I said that some packages can be considered to be well-maintained
even if they have only a passive maintainer because the amount of work
generated is very low. And I gave the example of a perl module.
> How do you obtain whether a group or a "passive" maintainer is working?
There's no evaluation at the group level, only individual developers can
be evaluated, "passive" maintainer are no different from any other
developers in the way that they are evaluated, just the expectation might
be different.
Anyway to respond to your question, that's to be defined but a combination
of mutiple data is to be expected:
- new upstream version available and not packaged since X days
- number of open bugreports increasing of X% per month in average over the
last 6 months
- some metric with lintian warnings
- standards-version not up-to-date
- number of release goals bugs open
- any other criteria that might count
- number of uploads in the X last months
- …
> Or how should this work? The problem in non-working teams is that every
> member trusts all the others and finally nothing will be done in
> case a problem occures. How do you want to address this
> problem?
If everybody answers that they are not responsible for a given package (ie
they state that they are "backups maintainers"), you know that you have a
problem with this package because nobody feels responsible for it.
At least with this system the problem is known, how to fix it is another
matter of course.
> Considering this example - I'm sure there are much more -
> leads me to the opinion that watching BTS for unanswered
> bug reports might enable us to detect MIA maintainers.
It's certainly one possible metric but not the easiest to retrieve and far
from something that can be generalized. Not all packages are equal and
you can't set the same expectations in terms of BTS answers for everybody.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: