On Fri, Mar 4, 2011 at 22:58, Steve Langasek <vor...@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. > It is not the function of the TC to kick over > anthills upon request (or at our whim). So far I have seen no proposed > intervention on the part of the TC that is demonstrably better than the > status quo, in either the short or long term, for the health of Python in > Debian; Can you please provide a list of pros/cons of the "status quo"/"proposed changes" that can make your belief more clear and transparent? I.e., I'd like to know what are the things that status quo is doing good and bad, and the same for appellants. Please also try not to be vague or twisting words, the ideal would be a schematic/concise list of pros/cons. That would really help understand what can be done better, from both parties. > and as there continues to be (slow but steady) forward progress on > the technical obstacles and policy issues that have made python packages so > contentious over the past years, I don't see any of this "slow but steady forward progress": can you please list them? > What I see lacking here above all is a good-faith committment from the > would-be package adopters that they will work to address the divergences > from upstream expectations in the dominant python extension packaging > paradigm. Can you detail why you don't see the commitment? can you point to discussion about those "divergences from upstream expectations" where they are explained and decisions were made? > Matthias has raised specific concerns in the past about > python-support behavior, which were discounted by the maintainer; work has > since been done to supersede python-support with a new policy and a new > helper in the form of dh_python2, with no constructive engagement by the > python-support maintainer (AFAIK) despite calls for input. Until dh_python2 > became a reality, the petitioners in this bug were (as I recall) all strong > proponents of python-support. So I am very concerned that a forcible > maintainer change here could have the effect of derailing the progress of > sorting out the python policy and helper behavior, as it would give the new > maintainers the freedom to ignore certain technical points of view. (And it > would be an easy thing to ignore, as well; But you have to be fair, and say all the truth here: you were also one of the most important supporter of python-central (the helper written by Matthias which received *a lot* of complains not completely addressed or discussed) and so your attack against python-support seems biased to me. (for the reader, this can be easily searched around May/June 2005 (or 2006?).) Also, please note that Piotr, before start writing dh_python2 strongly suggested to get rid of -central in favour of -support, and he made this suggestion to all his sponsorees, and the python modules team agrees with him start moving packages away from -central (with all the tech difficulties of removing by hand leftover files left there by -central) The improvements to the policy had nothing to do with -support, but only to the fact that the "at that time" maintainer of the policy (Matthias) let it rotten, without providing any update to it except for what he decided to be important and of course without any discussion; So the first big part of the update was to bring that up-to-date to the current status quo of packaging. Also, what is the last time you saw an update to the policy (with a proper upload)? I can tell you: 2010-08-13, about a week after the announced freeze, to introduce a change (X-Python-Version) discussed long before and never revamped before the change. Also Bazaar repo shows the last change was done on 2010-08-18: sorry but I can't call it "slow but steady" progress. > 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?) > Considering also that: > > - if everyone had been constructively engaging on this problem to begin > with, the occasion for the current python maintainer to engage in > brinksmanship with the python modules team would never have arisen; I hope you're sharing the blame half/half here, else can you please explain further? > - 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? > - 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 do not believe that forcibly changing the maintainer of the python > packages is the right thing for the TC to do. Could you please give a detailed description of why not? I don't see any here, except for a appreciable explanations of what Mathias did good, and the tiny improvements made, simply skipping the bad/wrong parts and the long way we have forward. > So my vote today would be: > > 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? Sirs, this bug is *one year* old, and proposing to simply take no action is kinda "surprising" to say the least (and not going into the 'strong words' area). > 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. > then > there would be reason to consider him an unsuitable maintainer. But in the > current situation I don't see any innocents and I don't see that hijacking > the package will make things better. see the first question in this email. On Fri, Mar 4, 2011 at 23:48, Steve Langasek <vor...@debian.org> wrote: > When maintainers of related packages are unable to work together, that is a > problem and something that the TC should be concerned about. But the notion > that important packages with a single maintainer are "problems to be solved" > is a specious one that is not worthy of the TC's consideration. true, but in this case the current situation of a single maintainer for python packages (in addition with the same person being the only maintainer for several other packages, very important and complex, and (on a side note) possibly poorly maintained) *is* relevant for this discussion. > 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. > Team maintenance is a reasonable practice to encourage, because in many > cases this will reduce the average turnaround on bugs; so you say that python bugs are all handled in a timely fashion? or are they left in the BTS until that python interpreter version is removed and thus they will get closed without any investigation/attentions? This has happened for 2.4, for a recent example. > but that's not true > in all cases, and treating this as a "problem to solve" maligns the enormous > contributions of single maintainers to Debian over the years. Ok, we now see that you think Matthias work has to be "venerated" no matter what. Sorry, but I think that's simply not true. I encourage you to look at [1] and tell me the "enormous contributions", for example, in bug fixing/replying. You know that maintaining important packages is just more that upload new upstream releases. [1] http://qa.debian.org/developer.php?login=d...@debian.org If you want to say that he takes the burden to maintain several difficult packages, we can only ack that and thank him for it, but saying "enormous contributions", against what's really happening is simply biased and unfair. But that's only a rebuttal to your implication, and it's (generally) off-topic for the discussion at hand. > The TC should > concern itself here with ensuring that the python packages are well > maintained which is not > and the python ecosystem within Debian is healthy, not either. > using > /whatever maintenance structure works best for the developers involved/, and > take no position on the essentially political question of team maintenance > as a rule. that's perfectly understandable. But how your proposal of "leave things as they are" would fix the above problems? Thanks for your time and interest on the matter, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
