On Mon, Mar 23, 2009 at 05:48:08PM +0100, Stefano Zacchiroli wrote: > [ 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 :-)) ] As already stated elsewhere I'm surely opening that topic somewhere with a broader audience, but its a good topic for me to see which opinions the DPL candidates act for. > 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. Stefano, actually I agree with its good intention. What I actually think is that we are kidding ourselves, because we already see whats needed, but don't go an active way of solving something which might be an issue. Instead we are acting only passive, with this note, with the best hope that someone will come and fix the problem. > > 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. No, actually its ok if we have more then one team. Some of these packages are already team-maintained and possibly good. What I aimed at was a team that backups existing teams and pitches in where team-power is missing. A team that is always responsible for packages, which are otherwise only in the responsibility of single maintainers. Such a team would always be empowered to make uploads for these packages, without needing to escalate single issues to the CTTE or comply with waiting periods for NMUs. > 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. Yes, asking the maintainer weither its okay, if a core-team can assist him with his duties, would be the normal way that should always be followed (even with my proposal). But it goes somewhat farer in that it it would make the members of that core team delagates with a given package set as their responsibility. It still needs volunteers to act in this team, but I think that a team which one can be part of makes volunteer positions actually more interesting as doing work, reporting it in the BTS and hoping some overloaded person will ever look into and considering it. Regards, Patrick
Attachment:
signature.asc
Description: Digital signature