[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#573745: Please decide on Python interpreter packages maintainership



Hello,
I'm going to reply to some of the more recent emails of this thread:
please consider this as a personal reply, not meant to represent the
feelings/ideas of other original signers of this appeal.

On Wed, May 12, 2010 at 23:28, Andreas Barth <aba@not.so.argh.org> wrote:
> * Josselin Mouette (joss@debian.org) [100512 17:27]:
>> Le mardi 11 mai 2010 à 23:08 +0200, Andreas Barth a écrit :
>> > However, there have been some talks within the tech ctte and with different
>> > people inside the Debian python community. That needed time, and we prefer
>> > to get to a resolution a bit later than to one that doesn't work. I doubt
>> > we can get to a final decision as of now.
>>
>> First of all I’d like to express my sadness to see these discussions,
>> again, having being conducted privately. We have now several years
>> behind us that show this is a bad idea, and the CTTE, asked to resolve
>> this matter, chose to adopt the same technique.
>
> So you think the only acceptable option is to take away the
> maintainership from Matthias? And even if we would do that, how can we
> be sure that this resolves all the issues we have?

Let's turn this way: we already know what it's like with him
maintaining python, and I'm quite sure it won't be worst, so at least
we have the occasion to see how a really community maintained (in the
sense of people coming from the python community) would work, and I
bet it will work well.

>> > I don't want to loose Matthias contributions to python
>> > within Debian and the python community.
>>
>> This is completely irrelevant, unless Matthias threatened to stop
>> contributing unless he can keep setting the rules. But I know the CTTE
>> wouldn’t take such “don’t touch my garden” blackmail into account, of
>> course.
>
> I would expect that deciding to remove him from being maintainer would
> demotivate him - at least that would be a natural thing to happen.

I can understand that, but are we only talking about python packages
or all the other packages Matthias maintains?

I think Matthias has concentrated in his hands a lot of powers, by
maintaining key packages (bash, binutils, gcc, java, python, and
several others), thus if the fear of removing him from python
maintainership is related to the fear of some of our most important
packages will be under-maintained (even if they *already* need a lot
more love than now) or even worst, sabotaged, I think we have a much
bigger problem than simply deciding who's to maintain python.

If we are threaten by the feelings of a single person for our core
packages, then I consider we're making a mistake and Debian is loosing
the control over itself, because of too much power in one pair of
hands, and we should fix this really soon.

I just hope to be over-pessimistic, but I also want to express one of
my fears about the "not remove Matthias from python maintainers"
proposal.

On Thu, May 13, 2010 at 11:15, Andreas Barth <aba@not.so.argh.org> wrote:
> * Josselin Mouette (joss@debian.org) [100513 03:09]:
>> Le mercredi 12 mai 2010 à 23:28 +0200, Andreas Barth a écrit :
>> > > > I don't want to loose Matthias contributions to python
>> > > > within Debian and the python community.
>> > >
>> > > This is completely irrelevant, unless Matthias threatened to stop
>> > > contributing unless he can keep setting the rules. But I know the CTTE
>> > > wouldn’t take such “don’t touch my garden” blackmail into account, of
>> > > course.
>> >
>> > I would expect that deciding to remove him from being maintainer would
>> > demotivate him - at least that would be a natural thing to happen.
>>
>> This line of reasoning is fallacious. I could reverse it and talk about
>> people who are demotivated because they feel the current maintainer is
>> incompetent. How could this help guiding the decision?
>
> Don't you see that we want to end that?

absolutely, thanks for the work you all do "behind the scene", and I
believe we are working towards this goal. I still think, tho, that in
strong situations, strong decisions have to be taken, else the
solution we reach will only work for some time, and then we'll fall
back to where we are now.

>> > > It means giving a veto power to Matthias about who can or cannot
>> > > contribute, while not giving this power to others.
>> >
>> > Eh, where does that proposal give Matthias veto power?
>>
>> If Matthias can refuse someone to be part of the core team because he
>> doesn’t trust that person, that’s a veto power.
>
> For the initial setup, I would like to have people in the core team
> that are ok by both Matthias and the people who brought this to the
> tech ctte (e.g. you). If that doesn't work out, we'll of course decide
> who is in the core team. I think that's reasonable.

Sadly, I think that the intersection of the two sets of "people
Matthias is ok with" and "people ok with the signer of this appeal" is
quite empty :) That's because I see Matthias as a single player, and
"forcing" him to work in a team will end up in:

1. him doing nothing
2. him keeps doing as of now, with more frustration for the others in that team.

Also, an additional level of "management" has to be well received from
who has to be managed: are we really sure Matthias will follow even
controversial decisions (so in opposition to some of his ideas) the
core team will take?

On Thu, May 13, 2010 at 15:21, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Andreas Barth writes ("Re: Bug#573745: python maintainance: next steps"):
>> For the initial setup, I would like to have people in the core team
>> that are ok by both Matthias and the people who brought this to the
>> tech ctte (e.g. you). If that doesn't work out, we'll of course decide
>> who is in the core team. I think that's reasonable.
>
> We should not forget the effect our approach here will have on other
> maintainers.  If we act now to give the existing maintainer a veto, to
> spare their feelings and avoid demotivating them, if perhaps it was
> they who were in a large part the reason for the bad situation, then
> we are saying to every maintainer that they do not need to worry: if
> they are at the centre of a storm of this kind, we will still honour
> their ownership of the package.
>
> Perhaps what you are forgetting is that the maintainer has a
> responsibility not just for the technical contents of the package, but
> also to facilitate other people's work as it relates to their package.
> The maintainer has a pretty much unfettered ability to delegate, to
> create a team of their choice, and so on; that comes with the
> responsibility to do so when appropriate.  So one thing we need to
> consider is whether in this case the maintainer has failed in that
> task.
>
> Or to put it another way, if the maintainer wanted help from a team
> acceptable to them, they could have simply decreed it.
>
> I think we do need to consider whether it would be best if the
> maintainer put their evident technical skills to use elsewhere.  Not
> just in the context of one package, but also to so that the project
> can see that if you really can't manage to work with people, and act
> as a blocker, you may be deposed.

Full and complete ack. Thanks for saying it, i couldn't be more direct
and precise. I subscribe all you said above.

On Sun, May 16, 2010 at 18:09, Luk Claes <luk@debian.org> wrote:
> On 05/13/2010 03:21 PM, Ian Jackson wrote:
>> Andreas Barth writes ("Re: Bug#573745: python maintainance: next steps"):
>> Perhaps what you are forgetting is that the maintainer has a
>> responsibility not just for the technical contents of the package, but
>> also to facilitate other people's work as it relates to their package.
>> The maintainer has a pretty much unfettered ability to delegate, to
>> create a team of their choice, and so on; that comes with the
>> responsibility to do so when appropriate.  So one thing we need to
>> consider is whether in this case the maintainer has failed in that
>> task.
>
> The question is indeed if the maintainer failed to properly maintain the
> package in the given circumstances. Note that the circumstances are by far
> trivial and that the maintainer showed only good intentions AFAICS. Note

this is at least debatable; I don't want to reiterate all the points
about python 2.6, just a couple: 14 months between upstream release of
2.6 and the upload in sid without a good reason (maybe some secret
ones?) and a complete disinterest in the 2.6 transition. IMO this is
not "only good intentions".

> also that the maintainer already welcomed some people to co-maintain, but

after a long long process of convincing him (and circumstances that
can be a little suspect); I won't call it "welcoming someone".

> hold strongly to some pre-conditions as he wants to avoid the real mess that
> resulted from the python 2.6 transition in Ubuntu.

ehm... the python 2.6 transition is the main blocker preventing from
freezing squeeze, so it ends up to be a huge a mess: these
pre-conditions didn't work, another big signal things must change.

On contrary of Ubuntu (that set 2.6 as default in 9.04, and since then
many packages were left broken, sigh), Debian managed to have skilled
people working on the transition, identifying packages with bugs,
filing them, NMU them and sponsor them when needed. Matthias did
nothing of these activity. You can call it "fingerpointing", but they
are facts: he doesn't participate in the transition, he wanted to
handle things his own way, and he want other people to "obey his
will", without complaining, and doing the actual work. Sorry, I won't
stand silent to this situation.

>> Or to put it another way, if the maintainer wanted help from a team
>> acceptable to them, they could have simply decreed it.
>
> That's true for the package maintenance, that is very well untrue for the
> circumstances and the policy changes he wants to have implemented to avoid
> similar trouble with the link farm as the ones that happened in Ubuntu.

this reduce to Debian being his playground for his Ubuntu activities?
Having the same maintainers between Debian and Ubuntu might be a nice
thing to have, but strongly not if the price to pay is to have Debian
always late then Ubuntu, or "half-baked" or the sandbox for policy
changes really aimed for Ubuntu, or anything else where Debian is not
leading the change.

>> I think we do need to consider whether it would be best if the
>> maintainer put their evident technical skills to use elsewhere.  Not
>> just in the context of one package, but also to so that the project
>> can see that if you really can't manage to work with people, and act
>> as a blocker, you may be deposed.
>
> That would rule out any of the vocal opposants as the new (co-)maintainers
> IMHO as they are as much part of shapening a blocker as the current
> maintainer AFAICS.

It's awkward to accuse us of being a blocker, given we are part of the
people who are really working on the python transition, as opposed to
the python maintainer: Luk, on what did you base your assumption?

Anyhow I, for one, would be more than happy not being a co-maintainer
of python interpreters packages, or part the core team, or whatsoever,
if that will lead to a solution of this really unpleasant situation
(Joss when was ruled out, maturely didn't complain about his
exclusion, but on the fact Matthias was still in); can you say the
same about Matthias? I don't this so, and now who's the blockers? I
can only suggest to try not to work against who's actually trying to
resolve this.

On Fri, May 21, 2010 at 18:13, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> 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.

Well, we are all volunteers, and we all know how much Murphy likes to
play with our free time exactly when we need it the most :)

>> 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.

I can understand that, and I really had hoped not to come to the point
where ctte has to be consulted for a decision.

> 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.

Indeed, fingerpointing won't solve this.

>> 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.

If we are going with the core team (no judgment implied here) I think
we have to clearly specify the powers/roles of the core team in
respect with the python maintainers (present and futures): I admit I
don't have that clear now :)

>> 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.

Thanks for saying it explicitly.

> 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.

Exactly, and as said above, we have to be sure that this new
management layer will be effective and well received from the people
that will have to interact with it.

> 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.

I had promised myself since weeks to wrote such an email, still didn't
managed to find the time to. I hope I'll be able to send it asap.
Anyhow (and I'd be explicit in that email too), what I will write
won't contain anything secret, and so I hope that (even if as a small
recap) the summary of all those emails will be made public at the end
of this appeal, and/or when decision of the core team will be made.

>> 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.

Absolutely agreed, that's another point where I fail to see Matthias
as a team player: as you already said, if he wanted a team, he could
have formed one ages ago.

On Sat, May 22, 2010 at 10:53, Andreas Barth <aba@not.so.argh.org> wrote:
> * 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.

absolutely, but that shouldn't mean that everyone is innocent or
everyone is guilty; instead, everyone has to take responsibility of
what he did and face the consequences of his own actions, either good
or bad.

> Given all the history and complaints I really believe we need an
> structural change to get things better. That's why I proposed one.

Ok, now I see your reason :)

Anyhow, to resolve this situation, it might also be enough a sane
collaboration between the python maintainers and all the python
community willing to help and support python in debian. Currently this
sane collaboration is missing.

I do acknowledge that the arrival of Scott and Piotr is helping a lot
in this direction, but the road is still long, and you know I still
consider the "blocker" for a resolution of this situation still
present.

>> We
>> understand there are other reasons that forbid to create a team
>> including both Matthias and Joss, though.
>
> I definitly agree to that sentence.

Ok, removing a bit the political face from me, I think it's a bit
unfair to rule out one person in favor of another. The more logical
solution seems to rule out both. But I also can see that not
considering Joss, would allow Matthias to still be in python
maintainership, which again, I don't consider an unchangeable
assumption.

>> 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.

As already said above, I don't know how many people respect the above
requirements. Sadly, it was created a deep cut between the current
maintainer and the whole python community of Debian, and that
community really works together (as you can see from #debian-python
and debian-python@l.d.o) so I doubt it is who generated the cut.

>> 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.

Me too.

>> 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.

Thanks for clarifying.

>> 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.

Well, let's hope that it won't introduce additional friction, but I
can see the point in having it.

>> 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."

ok, got it

>> 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"?

now it's clearer, at least for me.

On Tue, Jun 15, 2010 at 09:26, Josselin Mouette <joss@debian.org> wrote:
> Le samedi 22 mai 2010 à 10:53 +0200, Andreas Barth a écrit :
>> > 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’m only speaking for myself here, but I’m not OK with Matthias as part
> of the core team.

I'm not fine either: I think it will only concentrate additional power
in his hands, when I think we need (I'd really mean "should force
ourselvers") to remove power from him and giving it back to Debian.

>> I think that's fair for an start.
>
> If you really want to start afresh, you should consider pushing your
> reasoning to the limit: including only people that are OK by both
> Matthias and the people who appealed. That list includes neither
> Matthias nor myself.
>
> That would be fair. And that would ensure that people would try to think
> up new solutions out of the box, instead of re-hashing arguments from
> the past.

I agree with that.

Please, let me once again highlight that the lack of any public
statement from Matthias about this process (well, any public statement
at all regarding Debian since a long time) makes me very skeptical he
will ever be able to "recover" from his personal situation with other
Debian fellows, and so proposing a plan where he is always present
(and in key positions) is not what I consider a way to resolve this
issue.

Sorry for the long post, but I want to make clear what I think.

Thanks for your work & Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


Reply to: