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

Bug#573745: ping


On Sat, Mar 05, 2011 at 12:18:46PM +0000, Sandro Tosi wrote:
> On Fri, Mar 4, 2011 at 22:58, Steve Langasek <vorlon@debian.org> wrote:
> > I would vote against this.

> can you swear your NACK is completely unrelated to the fact you're a
> collegue of Matthias in
> Canonical/Linaro/whatever-umbrella-company-is-now? What I think it's
> important, is to understand if, and in what part, you judgement can be
> biased by external factors than just Debian technical ones.

For insight into why Matthias avoids communicating with you, you need look
no further than your own adversarial response to my message.  I am not on
trial here; cross-examining the members of the TC is not part of the
constitutional process.

I decline to respond to your base accusations.  I will only point out that
when you accuse your colleagues of conspiracy, consensus tends to be more

You do ask some other questions further on in your mail which are deserving
of a response in spite of the offensive overall tone of your message, so I'm
setting aside my first instinct to ignore everything you have to say on the
subject and am responding in-line.

> >  - failing to solve the policy for python helpers would mean there are
> >   outstanding *technical* disagreements that need to be addressed, not just
> >   social ones;

> Disagreement is also on the *actual* maintainership of the python
> interpreters packages and transitions handling, as we stated from the
> beginning and you might have skipped here: how's that going to be
> solved?

I think you are mistaken if you believe that disagreements over who should
maintain a package can be "solved" from the outside.  The TC has the power
to *decide* who the maintainer is of a given package; they don't have the
power to make everyone *happy* with that decision.

For instance, one of the options available to the TC is to decide that
Matthias should continue to be the maintainer.  This would fulfill our
duties under the constitution; but it wouldn't make you very happy, and from
your perspective it would not have "solved" the dispute over maintainership.
Likewise, if we oust Matthias, no disagreement has been resolved, only power

> >  1. reaffirm Matthias as the python maintainer, but encourage him to take
> > on comaintainers

> Ah, so do nothing and be gone with it? without even force him to take
> other guys in?

You seem to believe that forcing him to accept comaintainers is some sort of
a compromise solution.  You cannot force a developer to collaborate with
people he does not wish to.  Forcefully adding comaintainers to the package
is effectively equivalent to forcefully removing the original maintainer,
and is thus not a compromise at all.

> >  - solving the python helper Problem (which appears to be happening) removes
> >   the primary technical point of friction between Matthias and the modules
> >   team;

> Sure, but Matthias is in no way involved in this rewriting, since
> Piotr is only one doing it: how's that solving the problem between
> python ecosystem and Matthias?

First, your language here suggests that you regard Matthias as *outside* the
python ecosystem.  This reaffirms to me the presence of a very problematic
"us vs. him" attitude.  This is not at all unexpected, given the context of
a request to remove a maintainer, but it is a problem that you don't
consider the python maintainer part of the python ecosystem at all.  You
argue that the TC should force Matthias to accept comaintainers, but you
clearly don't regard him as a potential collaborator.

Second - you're correct that Piotr is the one writing the helper, and he
gets much kudos from me for his efforts here.  But you are again conflating
the social and the technical, where I'm trying to draw a distinction.  The
*technical* problem that needs to be solved is that for over half a decade
we've been without a consistent, agreed-upon description of how python
packages are supposed to interact in Debian, and as a result there are
packages working at cross-purposes.  That Matthias is not the one doing the
work to fix this is only relevant to the *social* problem, the lack of trust
and collaboration between the python maintainer and the python modules
maintainers which is largely secondary to the technical one (although it
certainly has legs of its own by now).  Solving the technical problem would
open the door to improved collaboration (and also clear the air so that the
TC could rule on the maintainership question *per se* if there were still
problems with the interactions between python and modules maintainers).  In
contrast, addressing the social problem by kicking Matthias out leaves the
technical issues unanswered.

The fact that Piotr is willing and able to work with Matthias to try to fix
the problems around python helpers in Debian in spite of the challenging
circumstances means that he is, to my mind, an ideal candidate to be a
python comaintainer with Matthias; but he has declined this suggestion.

> > And if the python package policy gets fixed and Matthias continues to be
> > uncooperative towards the python module team regarding transitions,

> Is there a time line for it? Speaking as a "downstream", who long
> should we tolerate this? 2.5 and 2.6 transitions were a mess, 2.7 we
> don't know since (strange ah?) he still didn't announce anything (and
> not that he had not made it yet in ubuntu), god only knows for 3.x -
> what else do you need to be convinced? I'm asking to understand what
> is the limit for CTTE to take actions, or be convinced there's a
> problem.

A timeline for fixing the python package policy?  No, how can there be?
This is up to the Debian python community at large.  (I don't think you can
credibly claim that Matthias is alone in blocking progress on this; you may
recall that the python policy is shipped in the python-defaults package,
which *does* have more than one maintainer.)

If you mean that the TC should set a timeline for settling the python policy
after which a decision would be made on python maintainership anyway, that
is not at all what I'm proposing.

If you would like the TC (or members of the TC) to participate in the python
package policy standardization, that would be a reasonable request and an
area where the TC's skills could probably be brought to bear with good
effect to speed up the process; but it's not what this bug report is about.

> > I don't think any of us will argue that communication on mailing lists
> > is Matthias's strong point.)

> So are we going to simply ignore it and pretend the problem doesn't exist
> and go on?  What are the measures CTTE would take to prevent this to be a
> problem in the future (as it was in the past and still *is* today) if the
> status quo has to be reaffirmed (as you so strongly want?)

The TC has neither the mandate nor the ability to prevent all future
communication problems with a maintainer.  The most I could say here is that
continued communication problems, in the absence of underlying disputes,
would be evidence that would cause me to reconsider my position on who
should maintain the package.

> On Fri, Mar 4, 2011 at 23:48, Steve Langasek <vorlon@debian.org> wrote:
> > There are plenty of clever developers capable of picking up where the
> > previous maintainer left off in the event of a "bus event", regardless
> > of the package or the packaging helper in use, and I have yet to see any
> > evidence that team-maintained packages are in better condition than
> > non-team-maintained ones (and I have plenty of anecdotes to the
> > contrary).

> So please be explicit and say those anecdotes, instead of just refer
> to them in a vague way: we all want to hear facts, not empty
> sentences.

Er, first, the plural of "anecdote" is not "data", and second, I'm not the
one arguing against the status quo wrt package maintenance within Debian -
which means I'm not the one who bears the burden of proof.

<snip various comments about Python>

The text I quoted from Stefano's mail was not about Python, and neither was
my reply.  Now, that makes both messages off-topic for this bug, but they
were also pretty *unambiguously* off-topic.

I think you should take a long, hard look at the biases you carry that led
you to interpret my comments as some kind of defense of Matthias when I was
clearly talking about the general *principle* of requiring comaintainers for
core packages.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: