[ ACK on the comment that proposals like this one deserve a wider audience than -vote and the candidates. Given you are asking, here is my answer, which does not inhibit re-raising the issue elsewhere of course (hint hint :-)) ]
On Sat, Mar 21, 2009 at 01:43:16PM +0100, Patrick Schoenfeld wrote:
> Some of these packages are very well maintained and others.. well,
> bug numbers sometimes speak for themselves. For these packages we have
> that cool text on the PTS pages: "The package is of priority standard
> or higher, you should really find some co-maintainers." which brought
> me on this at all. What I thought about when I read that is: "HaHaHa,
> we are kidding on us own, because we recommend something to us, what
> should actually be the default (for this type of packages).
I don't get what you mean here: it should be the default in which
sense? in the ideal world? agreed. Beside that, it is not written
anywhere that it should be the case. The warning is there because (as
I've mentioned elsewhere in this thread) the PTS has been used in the
past to push for QA practices which were considered good by the PTS
maintainers. That warning was implemented (IIRC, I haven't checked the
svn logs) by Raphael and has stayed there because the other people who
maintainer the PTS agrees with its good intention.
> Thats why I thought it would eventually be a good idea to form a
> core team, meaning a team of a bunch of people (10-20?), with
> wide-spread knowledge and known to have enough free time
> (e.g. people who have > 50 packages and aren't able to keep up with
> the bug reports in their own packages wouldn't qualify) that gets
> the job to (co-)maintain all these packages that are very important
> to us. It doesn't mean that the existing maintainers are taken away
> the packages, because they could still stay the maintainers, but
> obviously some of these packages are not easily maintainable by one
> person.
>
> What do you think about such a proposal?
It would make perfectly sense, but I fail to see its specificity. I
think that such important packages should be team maintained, even
only for backup reasons [1]. Is it that relevant for your proposal
that the team is a single one as opposed to multiple one? In practice,
I imagine that the overlap between maintenance team will grow over
time, so you can also see it as a gradual path towards your proposal.
Finally, let me observe that nothing in our current rules inhibit that
from happening: it would be enough to get the current maintainer
around an (IRC-)table, and decide to start over by asking for people
interested to join the forthcoming teams.
Cheers.
[1] but in practice for other good reasons, like team reviewing of
patches which are considered sensitive, like it happens on the
devscripts maintenance team for example
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{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
signature.asc
Description: Digital signature
