Discussion:
Bug#573745: ping
(too old to reply)
Stefano Zacchiroli
2010-11-06 20:16:32 UTC
Permalink
Dear Technical Committee members,
as you might imagine I got asked fairly often what is the status of
this issue. I've always made clear that any issue brought to the
tech-ctte is no DPL matter; the Constitution is very clear about that.

The only thing I could have done to help out a bit is trying some
informal mediation, not to leave out any potential solution.

I've indeed done a bit of that. I've spoken twice, with a delay of 6
months, with the Python maintainer face to face, trying to see whether
there was a possibility of an agreement on a new maintenance team which
would have made this bug moot (I'm sure that would have been made happy
also the tech-ctte :-P). I've also spoken, sometimes face to face and
sometimes in chat replying to "let's ask the DPL what's the status"
queries, to others people involved in this matter. Unfortunately,
nothing concrete has come out of that yet, most likely due to inability
on my side, more than to anything else.

On the bright side, I agree with others who have voiced their opinions
in this bug log that the situation is nowadays better than what it was
when this bug was reported. Not only we now have co-maintained
python*-defaults packages, but also (and more importantly) we now have
*discussions* on -***@lists.d.o on migration strategies and other
important topics. Those discussions include both Debian people and
upstream developers and might even hint future maintenance teams, which
is good. While it is true that the Python maintainer is not always
participating into them, it is also clear that he follows them and seems
to agree with where they are going.

Nevertheless, the big issue is undeniably still open: maintenance of the
main Python interpreter packages is still up to a single maintainer,
with no mutual trust and/or communication between him and (most of) the
rest of the Debian Python community.

Additionally, as DPL, I'm worried by seeing packages as important as the
Python interpreters maintained by a single person. Even if all other
surrounding issues were not there, that would be a bus-factor problem
worth fixing by itself. (I concede there are other similar situations
in the archive, but this is no excuse; they are just other problems to
be solved.)


All that said, one of the few remaining actions I can take on this issue
is to friendly ping the tech-ctte to actually decide on this issue, open
for 7 months now. I do think tech-ctte is a very useful device in Debian
and I want Debian to trust it as an efficient device; I would appreciate
if you can help me out toward this worthwhile goal.

If you think I can help in any other way, please let me know, I'll
gladly do whatever I can and/or I'm empowered to.


Thanks a lot for your work, you've all my sympathies for the decision
you're asked to make.

Cheers.


PS I appreciate Cc:-s to ***@d.o if you want to get my attention
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Caposella .......| ..: |.......... -- C. Adams
Stefano Zacchiroli
2010-12-26 10:57:17 UTC
Permalink
Post by Stefano Zacchiroli
All that said, one of the few remaining actions I can take on this
issue is to friendly ping the tech-ctte to actually decide on this
issue, open for 7 months now. I do think tech-ctte is a very useful
device in Debian and I want Debian to trust it as an efficient device;
I would appreciate if you can help me out toward this worthwhile goal.
If you think I can help in any other way, please let me know, I'll
gladly do whatever I can and/or I'm empowered to.
Thanks a lot for your work, you've all my sympathies for the decision
you're asked to make.
As ~2 more months have passed without a comment, I can't do any better
than pinging the CTTE again, AOL-ing the text above (especially the last
paragraph).

As the decision is fully in the hands of the CTTE, I don't see any other
way to help you out. But if you happen to know one, please let me know.

Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Don Armstrong
2011-01-04 04:58:11 UTC
Permalink
Post by Stefano Zacchiroli
Post by Stefano Zacchiroli
All that said, one of the few remaining actions I can take on this
issue is to friendly ping the tech-ctte to actually decide on this
issue, open for 7 months now. I do think tech-ctte is a very useful
device in Debian and I want Debian to trust it as an efficient device;
I would appreciate if you can help me out toward this worthwhile goal.
If you think I can help in any other way, please let me know, I'll
gladly do whatever I can and/or I'm empowered to.
Thanks a lot for your work, you've all my sympathies for the decision
you're asked to make.
As ~2 more months have passed without a comment, I can't do any better
than pinging the CTTE again, AOL-ing the text above (especially the last
paragraph).
I believe the CTTE needs to revisit this and see what the current
status is and if there are still remaining issues which need to be
worked through. I'll try to get a status report on this by the end of
this week and see where we are at.


Don Armstrong
--
UF: What's your favorite coffee blend?
PD: Dark Crude with heavy water. You are understandink? "If geiger
counter does not click, the coffee, she is just not thick."

http://www.donarmstrong.com http://rzlab.ucr.edu
Sandro Tosi
2011-01-04 08:11:34 UTC
Permalink
Hi Don & others,
Post by Don Armstrong
Post by Stefano Zacchiroli
Post by Stefano Zacchiroli
All that said, one of the few remaining actions I can take on this
issue is to friendly ping the tech-ctte to actually decide on this
issue, open for 7 months now. I do think tech-ctte is a very useful
device in Debian and I want Debian to trust it as an efficient device;
I would appreciate if you can help me out toward this worthwhile goal.
If you think I can help in any other way, please let me know, I'll
gladly do whatever I can and/or I'm empowered to.
Thanks a lot for your work, you've all my sympathies for the decision
you're asked to make.
As ~2 more months have passed without a comment, I can't do any better
than pinging the CTTE again, AOL-ing the text above (especially the last
paragraph).
I believe the CTTE needs to revisit this and see what the current
status is and if there are still remaining issues which need to be
worked through. I'll try to get a status report on this by the end of
this week and see where we are at.
Thanks for that, it's really appreciated!

If the re-evaluation will include a round of private conversations
with "key people", then I think it would be fair if you would also
include the original appellers that didn't get contacted in the first
place.

Thanks in advance,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Stefano Zacchiroli
2011-03-04 10:40:37 UTC
Permalink
Post by Stefano Zacchiroli
As ~2 more months have passed without a comment, I can't do any better
than pinging the CTTE again, AOL-ing the text above (especially the last
paragraph).
As the decision is fully in the hands of the CTTE, I don't see any other
way to help you out. But if you happen to know one, please let me know.
2 more months have passed, ... time for another ping :-)

As I feel bad about not having anything better to do than ping you, here
comes my last attempt to push this topic forward and, hopefully, get it
fixed within the current DPL term (of course, such a political concern
is not a CTTE concern, so you are more than free to ignore it).

The proposal is to delegate the decision on Python interpreter
maintenance to the DPL. No technical decision would be part of the
delegation, only the "social" problem of who are the maintainers will
be. There seem to be no specific provision in the Constitution about the
CTTE delegating decisions to others, but if the CTTE agrees on that
(ideally, voting on it), I think we'll be formally fine.

If the CTTE agrees, I will proceed as follow. I will propose, at my
discretion, a maintenance team that I hope could be accepted by all
involved parties. I'll ask for extra volunteers and for (motivated)
objections, trying to mediate in the discussion and reaching
consensus. All discussions will be public and happen on the
debian-python mailing list. Ultimately, I'll make a judgement call and
decide. People will be free to override it with the mechanisms we have
in place for that.

Of course, I will be way happier if the CTTE decides to beat me at this,
and decide upon this matter in a month or so :-)

Please consider this proposal of mine not as an attempt to step in CTTE
domain---this decision *is* fully within CTTE domain, there are no
doubts about that. Rather, it is the last attempt I can imagine to help
you out with this decision, given that all my previous (poor) attempts
have failed.

Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Ian Jackson
2011-03-04 11:33:27 UTC
Permalink
Post by Stefano Zacchiroli
2 more months have passed, ... time for another ping :-)
I have to say I'm very disappointed that we haven't managed to do a
better job of this. We need to find a way to make this decision which
does not become irretrievably blocked.

AIUI at the moment the blocking problem is that we don't have a
suitable new team. The selection of the new team is not something the
ctte is any good at, and selecting maintainers by private email
exchanges is bad anyway because it's not transparent, and also makes
it difficult to chase up. Furthermore I guess no-one wants to stick
their neck out.

I propose the following solution:

To: debian-devel, debian-python, existing python maintainer
Subject: python-* orphaned, help wanted

The Technical Committee have been petitioned to decide on the
maintainership of the python packes. We agree with the substance of
the complaint, but do not feel able to directly select the
replacement maintainers. Therefore:

We declare that the python packages (full list below) are now
orphaned, exercising our power in s2 of the Constitution.

Please would those interested in taking over Python maintenance form
an appropriate team and take over the package. If competing teams
should come forward, the package should be taken over by the largest.

Ian.
Steve Langasek
2011-03-04 22:58:01 UTC
Permalink
Post by Ian Jackson
AIUI at the moment the blocking problem is that we don't have a
suitable new team. The selection of the new team is not something the
ctte is any good at, and selecting maintainers by private email
exchanges is bad anyway because it's not transparent, and also makes
it difficult to chase up. Furthermore I guess no-one wants to stick
their neck out.
To: debian-devel, debian-python, existing python maintainer
Subject: python-* orphaned, help wanted
The Technical Committee have been petitioned to decide on the
maintainership of the python packes. We agree with the substance of
the complaint, but do not feel able to directly select the
We declare that the python packages (full list below) are now
orphaned, exercising our power in s2 of the Constitution.
Please would those interested in taking over Python maintenance form
an appropriate team and take over the package. If competing teams
should come forward, the package should be taken over by the largest.
I would vote against this. 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; 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 think the TC can do a lot of damage here.

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. 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; I don't think any of us will
argue that communication on mailing lists is Matthias's strong point.)

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;
- solving the python helper Problem (which appears to be happening) removes
the primary technical point of friction between Matthias and the modules
team;
- failing to solve the policy for python helpers would mean there are
outstanding *technical* disagreements that need to be addressed, not just
social ones;

I do not believe that forcibly changing the maintainer of the python
packages is the right thing for the TC to do.

So my vote today would be:

1. reaffirm Matthias as the python maintainer, but encourage him to take
on comaintainers
2. FD
3. delegate to the DPL
4. orphan the package and put it up for grabs

I don't think it's appropriate for the TC to delegate this to the DPL
either, but if Stefano were to act as a mediator for /non-binding/
arbitration on debian-python, I have no objection to this.

And if the python package policy gets fixed and Matthias continues to be
uncooperative towards the python module team regarding transitions, 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.
--
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/
***@ubuntu.com ***@debian.org
Sandro Tosi
2011-03-05 12:18:46 UTC
Permalink
Post by Steve Langasek
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.
Post by Steve Langasek
 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.
Post by Steve Langasek
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?
Post by Steve Langasek
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?
Post by Steve Langasek
 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.
Post by Steve Langasek
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?)
Post by Steve Langasek
 - 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?
Post by Steve Langasek
 - 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?
Post by Steve Langasek
 - 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?
Post by Steve Langasek
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.
Post by Steve Langasek
 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).
Post by Steve Langasek
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.
Post by Steve Langasek
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.
Post by Steve Langasek
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.
Post by Steve Langasek
 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.
Post by Steve Langasek
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.
Post by Steve Langasek
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=***@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.
Post by Steve Langasek
 The TC should
concern itself here with ensuring that the python packages are well
maintained
which is not
Post by Steve Langasek
and the python ecosystem within Debian is healthy,
not either.
Post by Steve Langasek
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
Vincent Bernat
2011-03-05 13:15:53 UTC
Permalink
Hi!

I am quoting Sandro message to answer to Steve one. Sorry.
 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;
Wow. Almost nobody uses python-central because python-support has a
friendly maintainer that helps people asking questions. Reversing the
situation seems quite biaised. For example, python-central does not
clean up old pyc files and there are numerous bugs report about this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518940
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466244
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479852

If you look at bug reports on python-support, you will notice that
Josselin is handling most of the bugs reported in a sane way. We did
use python-support because we get answers and fixes for our problems.
--
I WILL NOT CREATE ART FROM DUNG
I WILL NOT CREATE ART FROM DUNG
I WILL NOT CREATE ART FROM DUNG
-+- Bart Simpson on chalkboard in episode BABF04
Russ Allbery
2011-03-05 19:40:59 UTC
Permalink
Wow. Almost nobody uses python-central because python-support has a
friendly maintainer that helps people asking questions. Reversing the
situation seems quite biaised. For example, python-central does not
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518940
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466244
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479852
Steve's point was not in support of python-central, but rather in support
of the new helper process. I'm inclined to agree that, given the people
working on the new helper system, resolution of this bug one way or the
other is unlikely to derail it, but I think you're not seeing his point
and reacting to something else.
If you look at bug reports on python-support, you will notice that
Josselin is handling most of the bugs reported in a sane way. We did
use python-support because we get answers and fixes for our problems.
And all that happened without replacing the maintainer of Python. It
didn't happen anywhere nearly as smoothly as it could, but I think the
point is that Matthias is not blocking forward progress here, so changing
maintainers doesn't seem to be required to continue to make progress.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Russ Allbery
2011-03-05 19:37:28 UTC
Permalink
Post by Sandro Tosi
Post by Steve Langasek
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.
I'm in pretty much the same place that Steve is (seeing problems but not
convinced that the proposed solution is proportional to the level of
problems or will result in a net reduction of problems), and I don't have
any affiliation with Canonical at all and don't know Matthias from Adam.
I don't think you want to be playing that card.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Steve Langasek
2011-03-05 22:58:32 UTC
Permalink
Sandro,
Post by Sandro Tosi
Post by Steve Langasek
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.
Post by Sandro Tosi
Post by Steve Langasek
 - 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.
Post by Sandro Tosi
Post by Steve Langasek
 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.
Post by Sandro Tosi
Post by Steve Langasek
 - 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.
Post by Sandro Tosi
Post by Steve Langasek
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.
Post by Sandro Tosi
Post by Steve Langasek
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.
Post by Sandro Tosi
Post by Steve Langasek
 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/
***@ubuntu.com ***@debian.org
Russ Allbery
2011-03-05 19:55:06 UTC
Permalink
Post by Stefano Zacchiroli
If the CTTE agrees, I will proceed as follow. I will propose, at my
discretion, a maintenance team that I hope could be accepted by all
involved parties. I'll ask for extra volunteers and for (motivated)
objections, trying to mediate in the discussion and reaching
consensus. All discussions will be public and happen on the
debian-python mailing list. Ultimately, I'll make a judgement call and
decide. People will be free to override it with the mechanisms we have
in place for that.
I think, and have for some time, that the ideal situation would be a
maintenance team that includes Matthias (assuming that Matthias still
cares deeply about the Python packaging and wants to continue to
participate). If such a team could be found that would work well, it
would allow us to continue to make use of Matthias's passion for the work
while hopefully having a team that can fill in for and make up for the
shortfalls in skills and abilities of all the members, particularly
including communication and public planning.

The problem that I have with the curent situation is that kicking Matthias
to the curb seems to be a requirement for a resolution, and that makes me
really uncomfortable. I'm not, to note, saying I'm flatly opposed to
that, just that it makes me really uncomfortable and isn't something I
want to advocate given the information that's available to date.

For a maintainer team to work, though, just to be clear, it would need to
be a team of equals, not people who are just interpreting Matthias for
other people without the ability to make independent decisions.

I'm not sure delegating the decision is a good idea, but if you (or anyone
else) could come up with such a team, I think it would be a slam duck
solution to this, and I doubt there'd be much difficulty in getting CTTE
approval (assuming that it was even required, since if Matthias is happy
with the result, there's no need for the CTTE to take formal action).
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Stefano Zacchiroli
2011-03-09 18:18:16 UTC
Permalink
Post by Russ Allbery
I think, and have for some time, that the ideal situation would be a
maintenance team that includes Matthias (assuming that Matthias still
cares deeply about the Python packaging and wants to continue to
participate). If such a team could be found that would work well, it
would allow us to continue to make use of Matthias's passion for the work
while hopefully having a team that can fill in for and make up for the
shortfalls in skills and abilities of all the members, particularly
including communication and public planning.
I agree that, if acceptable by the rest of the "Debian Python community"
(whatever that means), the above would be a worthwhile goal.
Post by Russ Allbery
I'm not sure delegating the decision is a good idea, but if you (or anyone
else) could come up with such a team, I think it would be a slam duck
solution to this, and I doubt there'd be much difficulty in getting CTTE
approval (assuming that it was even required, since if Matthias is happy
with the result, there's no need for the CTTE to take formal action).
Fair enough, I'll consider starting myself a discussion about a
potential Python maintenance team on -python. It's still only a
"consider" as the tricky part is that, for various reasons already
mentioned in this bug log, it is unlikely that the current maintainer
will participate in a public discussion which can easily degenerate into
mud throwing. As a consequence of that, I believe it would also be hard
to obtain an explicit ACK from the current maintainers on additional
co-maintainers.

Let's assume for a moment (very hypothetically!) that a team can be
found which both includes the current maintainer and has rough consensus
on -python. Would the CTTE be willing to establish such a team as
Python interpreter maintainers, even in absence of an explicit public
ACK by the current maintainer?

(I duly notice that if the answer to the above is "no", we have evidence
of an easy DOS attack vector that can block this resolution forever.)

Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Ian Jackson
2011-03-09 18:31:29 UTC
Permalink
Post by Stefano Zacchiroli
Let's assume for a moment (very hypothetically!) that a team can be
found which both includes the current maintainer and has rough consensus
on -python. Would the CTTE be willing to establish such a team as
Python interpreter maintainers, even in absence of an explicit public
ACK by the current maintainer?
I would certainly be happy with that.
Post by Stefano Zacchiroli
(I duly notice that if the answer to the above is "no", we have evidence
of an easy DOS attack vector that can block this resolution forever.)
Quite so.

Ian.
Steve Langasek
2011-03-09 20:56:34 UTC
Permalink
Post by Stefano Zacchiroli
Fair enough, I'll consider starting myself a discussion about a
potential Python maintenance team on -python. It's still only a
"consider" as the tricky part is that, for various reasons already
mentioned in this bug log, it is unlikely that the current maintainer
will participate in a public discussion which can easily degenerate into
mud throwing. As a consequence of that, I believe it would also be hard
to obtain an explicit ACK from the current maintainers on additional
co-maintainers.
Let's assume for a moment (very hypothetically!) that a team can be
found which both includes the current maintainer and has rough consensus
on -python. Would the CTTE be willing to establish such a team as
Python interpreter maintainers, even in absence of an explicit public
ACK by the current maintainer?
(I duly notice that if the answer to the above is "no", we have evidence
of an easy DOS attack vector that can block this resolution forever.)
Do you mean that you would get a *private* ack from the current maintainer,
but no public one?

As commented in my previous mail, I don't believe that a maintenance *team*
can be formed without the consent of all involved, and that a forced team
eventually devolves into either a forced takeover or a failed takeover. (In
this case, since it's with the TC's imprimatur, it would presumably be a
forced takeover.) So I'm only willing to consider forming a team without
the explicit consent of the current maintainer under circumstances where I
think a forced takeover is also an acceptable outcome.

But as long as we have the current maintainer's agreement (in whatever
form), this concern is null. And if the problem is that the current
maintainer can DoS the process by not responding, I'm ok with giving an
ultimatum that we would go forward with a change unless Matthias responds in
a certain (reasonable) timeframe, provided that he still has the option to
say "no".
--
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/
***@ubuntu.com ***@debian.org
Stefano Zacchiroli
2011-03-09 22:28:08 UTC
Permalink
Post by Steve Langasek
Do you mean that you would get a *private* ack from the current
maintainer, but no public one? But as long as we have the current
maintainer's agreement (in whatever form), this concern is null.
I didn't mean to imply that I can get one but not the other. I just
wanted to share my impression that I see as unlikely that the maintainer
will publicly comment about that (while other people in this bug log
have already mentioned private discussions). I'll be happy to be proven
wrong on that point. I'm not convinced that a non-public agreement is
useful at this point, but it'd be better than nothing.
Post by Steve Langasek
And if the problem is that the current maintainer can DoS the process
by not responding, I'm ok with giving an ultimatum that we would go
forward with a change unless Matthias responds in a certain
(reasonable) timeframe, provided that he still has the option to say
"no".
This is a position I can understand, thanks for making it explicit.

Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Ian Jackson
2011-03-09 22:17:03 UTC
Permalink
Post by Steve Langasek
Do you mean that you would get a *private* ack from the current maintainer,
but no public one?
I am assuming that we are likely to get no ack at all.
Post by Steve Langasek
As commented in my previous mail, I don't believe that a maintenance *team*
can be formed without the consent of all involved, and that a forced team
eventually devolves into either a forced takeover or a failed takeover. (In
this case, since it's with the TC's imprimatur, it would presumably be a
forced takeover.) So I'm only willing to consider forming a team without
the explicit consent of the current maintainer under circumstances where I
think a forced takeover is also an acceptable outcome.
What I see in this case is this:

The current maintainer has completely failed to communicate with us at
all about the challenge and criticisms which have been brought before
us.

Under these circumstances I think our *only* reasonable decision is a
forced takeover as soon as a plausible set of replacement maintainers
are available.

One of the most effective approaches that the TC has had in resolving
disputes is to act as a kind of referee for the conversation between
two sides. When both sides can be persauded to be reasonable this
usually results in an amicable solution; when it doesn't, it becomes
obvious who is being unreasonable.

The current maintainer is making that impossible. Indeed the current
maintainer is making our task impossible. Whether that is a
deliberate strategy to stall us indefinitely, or simply
conflict-avoidant, is immaterial.

Or to put it another way, your current approach means that we are
blocked by the maintainer and have been for at least twelve months.
This blocking is likely to continue indefinitely. We need to unblock
this problem, which means we need to take waiting for or relying on
responses from the current maintainer out of the equation.

As Luca, one of the original petitioners, wrote:

Part of the problem is that Matthias is not communicating anymore on
public channels, and uses other people as a proxy.
...
Debian cannot live in a situation where the maintainer of a core
package doesn't even talk to people who directly depend on his work.
Post by Steve Langasek
But as long as we have the current maintainer's agreement (in whatever
form), this concern is null. And if the problem is that the current
maintainer can DoS the process by not responding, I'm ok with giving an
ultimatum that we would go forward with a change unless Matthias responds in
a certain (reasonable) timeframe, provided that he still has the option to
say "no".
What will you say if we get together some proposed new team, and
suggest it, and all we get from the current maintainer is the single
word "no" ?

Ian.
Andreas Barth
2011-03-11 21:57:28 UTC
Permalink
Post by Russ Allbery
The problem that I have with the curent situation is that kicking Matthias
to the curb seems to be a requirement for a resolution, and that makes me
really uncomfortable. I'm not, to note, saying I'm flatly opposed to
that, just that it makes me really uncomfortable and isn't something I
want to advocate given the information that's available to date.
For a maintainer team to work, though, just to be clear, it would need to
be a team of equals, not people who are just interpreting Matthias for
other people without the ability to make independent decisions.
I'm not sure delegating the decision is a good idea, but if you (or anyone
else) could come up with such a team, I think it would be a slam duck
solution to this, and I doubt there'd be much difficulty in getting CTTE
approval (assuming that it was even required, since if Matthias is happy
with the result, there's no need for the CTTE to take formal action).
fully agreed with.


Andi

Steve Langasek
2011-03-04 23:48:37 UTC
Permalink
Post by Stefano Zacchiroli
Nevertheless, the big issue is undeniably still open: maintenance of the
main Python interpreter packages is still up to a single maintainer,
with no mutual trust and/or communication between him and (most of) the
rest of the Debian Python community.
Additionally, as DPL, I'm worried by seeing packages as important as the
Python interpreters maintained by a single person. Even if all other
surrounding issues were not there, that would be a bus-factor problem
worth fixing by itself. (I concede there are other similar situations
in the archive, but this is no excuse; they are just other problems to
be solved.)
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. 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).

Team maintenance is a reasonable practice to encourage, because in many
cases this will reduce the average turnaround on bugs; 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. The TC should
concern itself here with ensuring that the python packages are well
maintained and the python ecosystem within Debian is healthy, 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.
--
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/
***@ubuntu.com ***@debian.org
Stefano Zacchiroli
2011-03-05 09:49:44 UTC
Permalink
Post by Steve Langasek
Post by Stefano Zacchiroli
Additionally, as DPL, I'm worried by seeing packages as important as the
Python interpreters maintained by a single person. Even if all other
surrounding issues were not there, that would be a bus-factor problem
worth fixing by itself. (I concede there are other similar situations
in the archive, but this is no excuse; they are just other problems to
be solved.)
<snip>
Post by Steve Langasek
Team maintenance is a reasonable practice to encourage, because in many
cases this will reduce the average turnaround on bugs; 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. The TC should
concern itself here with ensuring that the python packages are well
maintained and the python ecosystem within Debian is healthy, 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.
I do agree that whether the Python interpreter packages are team
maintained or not should not be a concern of CTTE. I disagree with your
evaluation of the risks, for Debian, of one-man-show maintenance for
important packages and I'll be glad to discuss this, but doing that here
would most likely be off-topic. My mention above was more of an extra
motivation of mine for delving into this, than an argument that the CTTE
should have taken into account.

Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Loading...