Re: Bug#573745: ping
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.
> 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 <vorlon@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=doko@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
Reply to: