On Mon, Mar 23, 2009 at 08:58:34PM +0100, Patrick Schoenfeld wrote:
> 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.
It is true that this way of approaching the issue is passive, but you
should consider from whom that "warning" was coming from: the PTS
maintainers. Their role is maintaining the PTS and they output
warnings in good faith trying to do something useful. In this precise
setting they appeal to no authority or consensus stating that
"important" packages should be team maintained, what else can they do?
(using "they" because this precise suggestion predates my PTS
involvement)
So the "we" that already see the problem is not, potentially, as broad
as you see it. I surely consider myself as a part of that we, though.
> 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.
Just to be clear on some details. I would be fine with both a single
team or multiple teams. However, I don't think it will be a good idea
to have official maintainers (teams or individual) and them something
else behind the scene stepping in only when something goes wrong or
when on a hurry uploads are needed. Teams work due to the
identification between declared maintainers (teams or individuals) and
the people actually doing the work. So, if there are people doing the
work they ought to be the maintainers/uploaders and vice-versa.
Turning this into a question for you: why the core-team you are
imagining as a backup should not become the actual maintenance team
instead of staying in the backup role? If the problem is not setting
aside the current maintainer, such maintainer should at least in the
beginning / interim be part of the new, forthcoming maintenance
team. I witnessed several maintenance transitions like the one I'm
imagining here, and it is IMO the best possible course of actions.
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