Re: Bug#573745: python maintainance: next steps
Hello,
thanks for the update, and sorry for this late reply.
On Tue, May 11, 2010 at 23:08, Andreas Barth <aba@not.so.argh.org>
wrote:
> sorry for not updating this request for such a long time - but things take
> longer than I'd like them to take.
we understand that it's not an easy task, involving several
sub-activities. 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.
> 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.
> The complaints are mostly non-technical. Re the technical parts, e.g. the
> discussion within Debian about "where to store files" brought two upstream
> proposals (PEPs) which would fix some disagreements in an good and
> forward way. I don't want to loose Matthias contributions to python
> within Debian and the python community.
Please let us reaffirm our "complains" are also technical: try not put them
aside just dealing with the personal situations around Python. In
several occasions (even recently) there were situations we can mention to
challenge the "technique" (either being the pure packaging
technicalities, or the attention/interest dedicated, or more); we don't
want to point fingers directly to those mistakes, but let's not reduce
this tech-ctte call to only feelings.
Talking about Python upstream, even if Matthias' contributions are
currently quite limited (but still present, and we thank him for that)
we feel they are done using his Canonical-employee hat (for example,
a recent email[1]), so not much a direct consequence of him being a DD
or the Debian maintainer; also note that both those PEPs (and we share
the believe they are a move forward) were not driven by Matthias (he
only reviewed them) so it's not holding that much your sentence.
[1] http://mail.python.org/pipermail/python-dev/2010-May/100183.html
Additionally, "Matthias contributions to python within Debian" are
exactly what we are challenging here, and they are at the very least
"debatable" (to not say "close to nothing" or "harmful for the Debian
project").
> The complaints are that the people in the Debian Python Community aren't
> enough involved in the decisions, and especially feel "left in the cold" re
> when to expect things to happen (or what are the reasons why they don't
> happen). The transition to use version 2.6 of python as default is just an
> example for most people involved (and was the reason finally the tech ctte
> was called in, but definitly not the only conflict).
> Parts of the conflicts date many years back, as well as the inability of
> some people to work together. The discussions have especially lead us to
> the conclusion that a team with both Matthias and Joss involved won't work.
We only would like to highlight again how we believe Joss is a very
highly technically skilled DD, and how his contributions to the Python
packages have been, and will be, profitable to the project. We
understand there are other reasons that forbid to create a team
including both Matthias and Joss, though.
> All in all, the situation isn't easy. Not easy for Matthias, not easy for
> anyone else and not easy for the technical committee. Please understand
> that our task isn't to decide who to blame for the current situation. Our
> task is to make sure that we can go to a better future. Probably our
> decision won't be totally fair and nice to all people involved. I can only
> say for my part that I try to be as fair and nice as possible, but an
> working solution is even more important. It's not about fault, it's about a
> good future.
We know, and appreciate that.
> So, where does that leave us? We need to establish an mechanismn that could
> resolve such conflicts before they can grow so large for years. We also
> need to have more people in the python packages maintainer field. We need
> to try to keep as many of our python people involved as sanely possible.
>
> In order to be able to get things going within the python community, we
> should establish a python core team that is trusted by all people involved.
>
> "Trusted by all people involved" definitly includes trusted by Matthias as
> current python maintainer, and trusted by the people who signed the request
> to the technical committee (of course, in worst case I'm willing to just
> decide on the membership of the core team). (There is an obvious conclusion
> who can't be member of the core team.)
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.
It seems you are trying to please Matthias very much, that's nice, but
what are the assurances you received he will behave differently from
now on? The fact that he didn't write a single word here makes us quite
skeptical if things will ever change. We are unaware of the discussion
you had with Matthias, but disclosing it is a core point of the problem
at hand, and always raising the "privacy wall" can't the way to go.
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.
We can pass the message that no matter how you maintain your packages,
no matter how badly you behave with your peers, no matter what you do,
you'll be grant forgiveness, and we'll pretend all of these never
happened and you'll be left in an advantage position over maintaining
your packages (even for the fear of possible repercussions in other
activities for Debian).
Or we can pass the message that we are a community (and not just a
bunch of geeky people) and we must act like one, so if you're
deliberately screw with your peers because you don't care for them, if
you feel so superior to them that you're not going even to speak to
them, if your interest in packages maintenance is so low and several
times you've uploaded "half-beaked" packages failing even the basic
pre-upload tests (like installing them) then we'll bring the packages
back to the community, where they belong to, and given in hands proven
to caring for them.
In this spirit, we'd like to emphasize Ian's reply to this thread.
> I think it would be good if at least one person (better two) in that team
> knows enough about python upstream to make sure Debian and upstream evolve in
> the same direction.
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.
> That team would also be the arbiter about disagreements re the debian
> python policy. Obviously derivations from upstream shouldn't happen easily,
> so I think there should be precautions that they happen without very good
> reason.
>
> Anyways, the first task of the core team would be to settle an decision
> policy. That policy needs also to include rules how the core team
> membership changes.
>
> Re the python packages maintainership, I propose to ask Matthias to get at
> least two more people involved who are ok for the python core team.
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. 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? If so,
how, and with which powers? What is the method to add new people to this
team (and/or replace someone resigning)?
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.
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.
Regards,
the proposers
Reply to: