Bug#573745: python maintainance: next steps
* Sandro Tosi (morph@debian.org) [100521 16:45]:
> Please let us reaffirm our "complains" are also technical: try not put them
> aside just dealing with the personal situations around Python.
I know.
However, we basically have two chances re the technical side: Either
we could start micro-managing decisions within debian python
(especially as there is more than one topic where there are different
opinions), which I don't believe is efficient. Or not.
Also, I don't want to end in the finger pointing game - and looking
back, I can see mistakes with almost everybody involved (including
myself). But it doesn't help to say "this person made more mistakes
than that person", because that'd only get very messy.
Given all the history and complaints I really believe we need an
structural change to get things better. That's why I proposed one.
> We
> understand there are other reasons that forbid to create a team
> including both Matthias and Joss, though.
I definitly agree to that sentence.
> As already pointed out by Joss in another email, is Matthias being
> granted with a veto vote? Can he indefinitely veto people willing to
> join such team even if others are OK with them? If that's the case, we
> believe this simply won't work and would kill democracy.
For the initial setup, I'd like to have only people in the team that
are ok by Matthias and are ok by the people who appealed to the
tech ctte. If that doesn't work out, we'll have to just decide anyways
of course.
I think that's fair for an start. For the future replacements, it's up
to the group of people how they add new people.
> We recently saw Barry Warsaw more involved, which is very positive. We
> don't know if you already contacted him, or if he would accept, but he
> would be a good candidate, especially one who doesn't have a history in
> Debian.
I heared good things about Barry at other places as well, so I'd
consider him an candidate.
> 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.
Right (so I'd assume that there will be some overlap soon) - of
course, you (the python developers together) can change things as you
consider them fit.
> If that's the case, what are the
> powers of this team over the Python maintainers? Can the core team
> force maintainers to implement something or fix a given bug?
I'd expect them to have powers the same way like e.g. the release
team. Who don't have that much formal power, but anyone involved
knows that they're good, knowledgable and you better behave like they
want. Obviously also if that team would complain to the tech ctte,
it's way easier to accept an complaint.
> What is the method to add new people to this
> team (and/or replace someone resigning)?
"Up to the team to define, but they need to do that pretty soon."
> 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.
Can we put it as "there needs to be a team of same-power developers;
we don't mind too much how this is expressed in the fields of the
package or not"?
Andi
Reply to: