Sandro, 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 elusive. 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 transferred. > > 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