Re: Self-assessment of the quality of the maintenance work
On Mon, 22 Dec 2008, Lucas Nussbaum wrote:
> Your main goal is to improve our detection of packages that need
> attention. (it would also help detect inactive maintainers, but even
> that has the goal of improving the quality of our packages).
Not only. One of the aspects that I like most in this proposal is that it
will be possible to have a list of packages that are not orphaned but that
have only a passive maintainer who would be happy to find an active
maintainer (and possibly sponsor him if needed).
For new maintainers, it would contain more interesting packages than
the set of orphaned ones (where important packages get adopted fast and
that tend to contain mostly marginal software).
I know that it is similar to the RFH/RFA that we have in WNPP but that
system is IMO not working because:
- too few maintainers are using it, thus looking for packages to help
there is not really interesting (not enough "choice") and thus the
system is not very efficient
- the maintainers need to be aware of the system and must convince
himself that it will be useful to make the effort to report the bug
Of course, those problems will only be solved for the new system if
participation is very large (and hence will probably be better only if
participation gets mandatory at some later point).
The second point is that such a system should bring maintainers to
give away their packages as soon as they realize that they are
not active anymore (hopefully no later than 6 months after they stopped
taking care of it) and not years later (after the package accumulated
bugs, and that it got detected by our current rules).
> However, I have the impression that currently, we do pretty well at
> detecting packages that need attention.
I don't know if we do well, but I agree that it's easy to identify a large
set of packages that need attention and that we most certainly have a backlog to
> What we don't do very well, is taking care of those: we have tons of
> orphaned packages, and tons of packages that need investigation
> according to Bapase. So that's probably where we should put more work.
Would some part of the "need investigation" be solved/solvable with
some specific questions added to the form that I try to describe ?
Otherwise I agree that we should do better at handling those already
identified but except for the "recruiting team" I have no specific idea
to help solve this problem.
Le best-seller français mis à jour pour Debian Etch :