Re: Question to Stefano, Steve and Luk about the organisation into packaging teams.
On Tue, Mar 24, 2009 at 09:46:31AM +0100, Stefano Zacchiroli wrote:
> 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)
Sure. Its no criticism targetted at the PTS maintainers. Its not even
criticism at all. Its just noteing that it got the attention of someone,
but it seems it didn't get the attention of the project. Which would
be quiet important, because those packages _are_ very important
for our project.
> 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.
ACK.
> > 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.
Good point. There are two problems I see:
If we have a single core team, which is responsible for about 100
packages all alone, I guess we will quickly see those people beeing
overloaded. Second, the existing maintainers surely do some valueable
work and it would be a shame to take the work they do away from them.
I think such a new core-team would also be a good chance, to attract
some fresh blood. So how to proceed from here? It seems that the only
solution is...
> 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?
.. to make the core-team the actual maintenance team and asking the
existing maintainers to join it. In the end I don't have a problem
if this team is somewhat bigger. What I think is valueable about such a
team is the effects that come from beeing part of a team and beeing
responsible.
> 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.
Right.
Cheers,
Patrick
Reply to: