On Fri, Mar 20, 2009 at 01:00:39PM +0100, Luk Claes wrote:
> >> people. My proposal would be to add a "join a team" entry as one of
> >> the *recommended* step in our join checklists.
>
> I agree that this is a good idea.
Cool.
> > Let me add a second way to implement that default; I've split it
> > in a different mail because it touches a different subject:
> > handling of sub-standard quality packages. We need ways to
> > identify them and to, initially gently and then more forcibly if
> > needed, encourage maintainers to pass over maintenance. How to do
> > that is a different topic, let's assume we have a way to identify
> > such packages.
>
> I think it's important to foremost work together with the maintainer
> on this. The goal should be that the maintainer is more proactive in
> the future and we would not get sub-standard quality packages for
> them that easily anymore.
Yes, but at this abstraction level it is so vague that we cannot
really learn anything from it. How do you plan to ensure that that
will be the case? Neglected packages are in most case a signal of the
maintainer attention having moved elsewhere.
The most likely outcome is to pass over maintenance to somebody else,
which usually happens when the maintainer is still responsive enough
to publicly look for help by creating a maintenance team. Then, IME,
what will inevitably happen is that the new maintenance team will
completely take over the package. When this happens we have no problem
to fix ...
> I don't think it's a good idea to take over packages from existing
> maintainers unless that maintainer agrees with it or is not active
> anymore. Proposing the maintainer to join existing teams maintaining
> similar packages is a good idea though.
... the problem we have to fix is when the maintainer is not reactive
enough to look for help.
There, the QA team stepping in and suggesting to ask for help
(publicly, so that we have it traced) and suggesting the formation of
a maintenance team can be an interesting evolution.
> > Finally, I believe our most important packages (e.g., as defined by
> > their archive Priority or shared libraries with tons of reverse
> > dependencies) should be team-maintained, at least to provide backup
> > maintainers. In fact, the PTS already implements such a warning on a
> > Priority basis (implementation by Raphael, a while ago); similar
> > warnings can and should be added to other tools of our toolchains.
>
> Not a bad idea, though it's only a 'should' and should not be
> interpreted as a 'must' IMHO.
Agreed.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature