Re: Self-assessment of the quality of the maintenance work
Responding to myself to share other details related to this idea
that I didn't want to include in the initial mail.
On Sat, 20 Dec 2008, Raphael Hertzog wrote:
> The basic idea is quite simple, we want to ensure that each package is
> maintained as well as possible and for this we need to ensure that
> it has one or more active maintainer(s). Hence every X months, each
> maintainer receives a mail with a link to a web form where he'll have a
> list of all the packages that he maintains/co-maintains and for each
> package he has to answer several questions that explain his relationship
> with the package (the answer are preseeded with the values he selected
> the previous time so that he can quickly skim over it if nothing has
One of the side-effects is that we would encourage maintainers to remove
themselves from the Uploaders field if they are no more maintaining the
> - what kind of maintainer he is
> - active (responding quickly, forwarding bugs, …)
> - passive (responds only to major problems)
> - backup (not doing anything unless solicited)
> - if the package needs an active maintainer or not (most perl modules are
> well maintained with a single "passive" maintainer)
> - if the package needs help from another volunteer
If you find the idea interesting, I'd appreciate your input on
the different categorization of maintenance type that we should propose
and what are the main characteristics of each category.
I have been rather superficial in the description above but it matches at
least part of my view on maintenance work: there are packages that I care
a lot about and where I will do my best and there are packages that I
packaged only because they are dependencies of other stuff that I needed
and where I'm not following upstream developement at all. I tend to do the
minimum for those (handle only RC-bugs in a timely fashion, package
new upstream versions often several months after its publication, …) and I
would be glad to let someone more involved take over those packages.
> The collation of all those data will give us a better view on the
> maintenance status of each package and it could be displayed on the PTS.
It could also be used to create a new "maintenance" facet in debtags.
maint::orphaned, maint::active, maint::passive, maint::help-needed,
Le best-seller français mis à jour pour Debian Etch :