Re: Bug#573745: python maintainance: next steps
Sandro Tosi writes ("Re: Bug#573745: python maintainance: next steps"):
> Please also understand that not receiving any update
> could give the impression that nothing is being done (that turned out
> it's not this case, but still), so a periodic update like "we're still
> talking to people, don't worry we're working on it" it's important.
Yes, I agree. Sorry, we're not as good at that as we should be. We
will try to be better, but also I encourage you to prod us if we seem
to have gone quiet. So, thanks for chasing us.
> Situations likes this one happened and will happen again (sadly), and the
> resolution of this case will be an example case on how such things will
> be handled: we have the occasion here to show how Debian acts in
> situation where there is some real disagreement in package
> maintenance.
I absolutely agree.
> We can pass the message that no matter how you maintain your packages,
> no matter how badly you behave with your peers, [...]
I think part of the problem is that many of us are reluctant to get
into that kind of "blame game", as it's messy and subjective and
unpleasant. But really I think if we have a situation like this one
we have to look at the history (and that does take work and it's often
not fun reading old flamewars) and yes we do have to make a judgement
about what has gone before.
That doesn't mean that we have to come out and explicitly point the
finger. But we should take these matters into account.
> So are you proposing to form the Python core team as an entity
> separated from the Python maintainers? Like an entity supervising the
> activities of Python maintainer? We are not criticizing the idea, it's
> just to understand the proposal. [...]
As I understand it the idea currently being proposed is to create a
new Python core team, and decree that that team are the new
co-maintainers of Python. After that intervention by the TC the core
team would be self-governing as with any other package maintenance
team - including the ability to hire and fire its own members.
Developers who wish to work on Python, but who aren't in the core
team, will have to work through the core team just as any developer
who isn't a maintainer works on any other package - that may or may
not include being given whatever conditional or unconditional upload
(or nmu) or commit rights the core team decides.
> What we are about to ask seems to be only a minor detail but it's a
> fundamental change of perspective: we think that Python Maintainer
> role should be assigned to a team (maybe the pkg-python alioth team can
> be resurrected) and not to a single person, so with real maintainers in
> Uploaders. The reasoning is we would like to see a team of peers, not
> with one developer to take decisions alone.
Yes. I think we are all agreed on this. The question is who should
be on this team. My view is that it should consist of people who have
the necessary technical and personal skills, and a history of interest
in the Python packages in Debian. It should contain around 4 or 5
people.
I don't think anyone should be given a veto over the membership of the
core team. So specifically, the fact that we don't believe Matthias
will be at all happy, with some possibilities for the core team, does
not mean that those possibilities are unacceptable.
But we do need to consider every person on their own merits and look
at their contributions as a whole and we should pick people who have a
history of constructive engagement - this is as much a management role
as a technical one.
Another difficulty is that it is very difficult to do this kind of
appointment without any private discussion. We need to be able to
take private input from people who may be reluctant to say "well I
know Alice has done a lot of good work but she's a bit of a loose
cannon - look at that gnomovision fiasco last year <url>" in public.
So can I make a suggestion ? How about we have people send in
privately names that you think would make excellent candidates. Email
them to any TC member and we can pass it on to the other TC members by
private email.
> One solution which helped much in other teams was to chose one person,
> which is not part of the team, as the only one who is allowed to upload
> the packages and who ensures that fights about changes (they should not
> happen anyway, but this might keep the heads cool) won't end up with a
> mess in the upload queue. We suggest to use this only as a last resort
> solution.
The team must not include anyone who will play Core Wars in the
archive against the other team members. The team should have a good
internal working relationship - that doesn't mean never disagreeing,
but it does mean dealing constructively with disagreements and
honouring the consensus of the team if it goes against you.
So this situation should not arise.
Ian.
Reply to: