Debian Bug report logs - #573745

Please decide on Python interpreter packages maintainership

Reported by: Sandro Tosi <morph@debian.org> Date: Sat, 13 Mar 2010 16:39:01 UTC Severity: normal Done: Don Armstrong <don@debian.org> Bug is archived. No further changes may be made.

Toggle useless messages

Report forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Sat, 13 Mar 2010 16:39:04 GMT) (full text, mbox, link).

Acknowledgement sent to Sandro Tosi <morph@debian.org> :

New Bug report received and forwarded. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sat, 13 Mar 2010 16:39:04 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Sandro Tosi <morph@debian.org> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: Please decide on Python interpreter packages maintainership Date: Sat, 13 Mar 2010 17:24:51 +0100

Package: tech-ctte Severity: normal Hello Technical Committee, we'd like you to decide about how the Python interpreter packages should be maintained in Debian. The problems that we have with the current situation can mostly be described by having a look at the way the Python 2.6 transition is being handled. 1. The Python maintainer delayed the upload of version 2.6 for 14 months since the first upstream release, without giving a valid technical reason for doing so. At the same time, the same maintainer uploaded said Python 2.6 package quickly to Ubuntu, which released twice with this version as default before it was uploaded to unstable. 2. When finally uploaded, the python2.6 package contained an unplanned transition to a new location for installed modules. This solution was not discussed at all with other maintainers and led to major changes having to be rushed into all packaging tools, and hundreds of packages left to be fixed. 3. The Python maintainer didn't provide any kind of impact analysis of this transition, leaving all the burden on other maintainers (mostly the Python modules team) and didn't try to set up dialogue with the team, which was left to file bugs and do NMUs so that packages could build cleanly with these changes. At the same time, the same maintainer provided a very thorough analysis of the upcoming changes in GCC 4.5, collaborating with other developers to test them on a large scale, and thus proving he has all technical and communication skills to do this. 4. The Python maintainer delayed adding python2.6 to the supported versions, asking for python2.4 to be removed first. It is a good thing to remove python2.4 of course, but it could have been done later (or earlier), without delaying the former important step. 5. The Python maintainer didn't provide an environment where maintainers could test their packages with python2.6 as default in experimental, which is something that was asked since he announced the 2.6 transition. Again, the Python modules team was left the burden of setting up test environments, filing bugs, helping other maintainers to fix their packages, preparing and sponsoring NMUs, etc. When asked about this situation, he replied indirectly (using another developer as a proxy) that he is working on adding additional features unrelated to the transition before this happens. 6. The Python maintainer has still virtually zero communication with the Debian Python modules and Python applications teams, and there seems to have been no significant progress in this. This situation is not new. Similar problems occurred for previous Python transitions, starting as early as python2.2 and getting worse over the time, despite the increasing amount of work put in Python-related tools and of people involved in Python packaging. A common pattern is that he often blocks important transitions to force some controversial, unrelated technical changes to be implemented before these transitions happen. Given all these points, we think that the current Python maintainer has no real interest in maintaining Python in Debian, and no interest in working in an open fashion with other people committed in this area. Therefore, we.d like to move the maintainership of pythonX.Y* (interpreters and related packages) and python-defaults (due to its specific role in the Python environment) packages to a team of people that already showed their involvement in Python in Debian, their ability to work in a team, and their will to bring a constant attention to Python in Debian; among them we propose ourselves: - Luca Falavigna <dktrkranz@debian.org> - Josselin Mouette <joss@debian.org> - Sandro Tosi <morph@debian.org> - Bernd Zeimetz <bzed@debian.org> - anyone else willing to help, including of course the current maintainer, provided the above points are met. Thanks to the amount of work the Python modules team has done for this transition, Python 2.6 can now become the default version in unstable (of course after the approval of the Release Team) with minimal breakage, so that time can be the smoother one to hand the package over to a team. Thanks for your attention, Luca, Josselin, Sandro, Bernd PS: attached you can find the same text along with our signature of it. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Sat, 13 Mar 2010 20:06:02 GMT) (full text, mbox, link).

Acknowledgement sent to Bdale Garbee <bdale@gag.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sat, 13 Mar 2010 20:06:02 GMT) (full text, mbox, link).

Message #10 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Bdale Garbee <bdale@gag.com> To: Sandro Tosi <morph@debian.org>, 573745@bugs.debian.org Cc: doko@debian.org Subject: Re: Bug#573745: Please decide on Python interpreter packages maintainership Date: Sat, 13 Mar 2010 13:02:30 -0700

On Sat, 13 Mar 2010 17:24:51 +0100, Sandro Tosi <morph@debian.org> wrote: > Package: tech-ctte > Severity: normal > > Hello Technical Committee, > we'd like you to decide about how the Python interpreter packages > should be maintained in Debian. Thank you for bringing this to the Committee's attention. However, I was a little surprised to see this filed without a CC to the current package maintainer. It seems our next step should be to invite him to comment on the issues raised from his perspective. Matthias? Bdale

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Sat, 13 Mar 2010 21:03:03 GMT) (full text, mbox, link).

Acknowledgement sent to Sandro Tosi <morph@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sat, 13 Mar 2010 21:03:03 GMT) (full text, mbox, link).

Message #15 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Sandro Tosi <morph@debian.org> To: Bdale Garbee <bdale@gag.com> Cc: 573745@bugs.debian.org, doko@debian.org Subject: Re: Bug#573745: Please decide on Python interpreter packages maintainership Date: Sat, 13 Mar 2010 21:59:32 +0100

Hello, thanks for the fast reply. On Sat, Mar 13, 2010 at 21:02, Bdale Garbee <bdale@gag.com> wrote: > On Sat, 13 Mar 2010 17:24:51 +0100, Sandro Tosi <morph@debian.org> wrote: >> Package: tech-ctte >> Severity: normal >> >> Hello Technical Committee, >> we'd like you to decide about how the Python interpreter packages >> should be maintained in Debian. > > Thank you for bringing this to the Committee's attention. However, I > was a little surprised to see this filed without a CC to the current > package maintainer. It seems our next step should be to invite him to > comment on the issues raised from his perspective. Well, I didn't know how you want to conduct the request, so didn't set any CC (neither Matthias nor co-signers), taking the more cautious side. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Wed, 17 Mar 2010 22:54:06 GMT) (full text, mbox, link).

Acknowledgement sent to Bdale Garbee <bdale@gag.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 17 Mar 2010 22:54:07 GMT) (full text, mbox, link).

Message #20 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Bdale Garbee <bdale@gag.com> To: Sandro Tosi <morph@debian.org>, 573745@bugs.debian.org, doko@debian.org, leader@debian.org Subject: Re: Bug#573745: Please decide on Python interpreter packages maintainership Date: Wed, 17 Mar 2010 16:50:45 -0600

On Sat, 13 Mar 2010 17:24:51 +0100, Sandro Tosi <morph@debian.org> wrote: > Package: tech-ctte > Severity: normal > > Hello Technical Committee, > we'd like you to decide about how the Python interpreter packages > should be maintained in Debian. I've spent several hours since my last message communicating with the current Python maintainer, reading various mailing list threads and bug logs, and generally trying to understand the situation as best I can. It bothers me that what you've brought to the TC is a rant about your frustrations culminating in a request to remove someone else from their role, rather than a crisper articulation of what's wrong and a plan that explains how we should move forward. In my reading and discussion with others, there are hints about different agreements at different times between different people about how to handle various transitions, but as someone not party to the various discussions over time, I wish I could find a single, well articulated policy for Python in Debian. There are more people I want to talk to, and perhaps one or more of them will make everything clear to me... but I do not want to delay things further. I realize this may not be what you had in mind when you asked the TC to "decide about how the Python interpreter packages should be maintained in Debian", but now that you've opened Pandora's box, I believe we have a responsibility to understand the underlying problems that apparently have plagued Python policy for years, so that whatever decision we take will ensure the most positive outcome for Python handling in Debian in the future. I'm adding the DPL to this reply because it seems possible that the only way to achieve this objective might be an in-person Debian Python Summit meeting, moderated by members of the TC, where we can work through all the issues and come to consensus. Perhaps we can resolve our problems by email and/or IRC, but the mere existence of this petition to the TC and what it implies about communication disconnects makes me doubt that. Before I'll be willing to support any Technical Committee action on this petition, I believe we need a detailed and competent plan articulated, that explains how we get from where we are today to a single policy for Python in Debian, and that covers at least: 1) our philosophy for handling multiple Python interpreter versions 2) the supported approach(es) to packaging Python modules 3) an analysis of the effort involved and who needs to do what 4) a tentative schedule of milestones to completion, including what can and should be done before squeeze freeze 5) explicit commitment by involved parties to do the required work > transitions to force some controversial, unrelated technical > changes to be implemented before these transitions happen. I think this is a key part of the problem. The Python maintainer does not seem to believe that these are unrelated technical issues. And the controversy that does exist seems now to be more fueled by a combination of emotion and inertia than technical concerns. We need to get past that, and focus our attentions squarely on a good Python technical policy and associated implementation plan. I think everything else will flow fairly easily if we can accomplish that. Bdale

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Thu, 18 Mar 2010 17:03:09 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Thu, 18 Mar 2010 17:03:09 GMT) (full text, mbox, link).

Message #25 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org> To: Sandro Tosi <morph@debian.org>, 573745@bugs.debian.org, doko@debian.org, leader@debian.org Subject: Re: Bug#573745: Please decide on Python interpreter packages maintainership Date: Thu, 18 Mar 2010 17:59:21 +0100

* Bdale Garbee (bdale@gag.com) [100318 00:00]: > I'm adding the DPL to this reply because it seems possible that the only > way to achieve this objective might be an in-person Debian Python Summit > meeting, moderated by members of the TC, where we can work through all > the issues and come to consensus. Perhaps we can resolve our problems > by email and/or IRC, but the mere existence of this petition to the TC > and what it implies about communication disconnects makes me doubt that. I agree. I tried to get one such meeting done some time ago (see below). I can understand if people are so frustrated now that they escalate to the tech ctte. However, at least at this time I don't think I'll vote for a new maintainer (team) if we didn't at least try to resolve the basic issues before. Andi From: Andreas Barth To: doko, joss, zack, bzed, piotr, dktrkranz, scottk Cc: leader, release team Subject: status of python / face2face-meeting? Date: Sun, 27 Sep 2009 13:32:47 +0200 Message-ID: <20090927113247.GH9745@mails.so.argh.org> Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.5.18 (2008-05-17) [ mail adresses removed -- Andi, 18.3.2010 ] [ second sidenote - the recipient list of the mail is not necessarily complete - please feel free to suggest additional recipients, I'm happy to include more people ] Hi, as part of the recent release mails, we got some - well, "complaints" is the wrong word, but definitly in that direction - mails about python2.6 (or rather its inexistence in unstable). Also there doesn't seem to be a common mindset how to place files etc etc, see e.g. http://bugs.debian.org/474630 (this is an example, not a "there needs to be some action now"). As you might know, I'm not a member of the Debian Python Community, but I'm a member of the Release Community, and I'm a frequent python user/code writer (actually the language of my choice for many tasks). For this reason, it might be that I didn't pick up all the necessary/recommended people for this mail - sorry if I have, I don't want to step up on anybodys toes. From my discussions on IRC, I have the impression that all involved people are unhappy with the current situation, that there are still some issues lingering around for quite some time, and this combination makes it impossible to resolve the (real) issues we have. On the other hand, it seems to me that overall python packaging has progressed in Debian quite much since I last looked at it, and I think we should try to build up on our experiences since 2006. For this reason, I'm proposing to meet us all for a weekend in real, and try to get the root issues resolved then and there. This of course means getting an agenda in time before the meeting. This also means that we definitly need to meet us on Friday evening latest so that we have really the full Saturday to understand the reasons people have for their wishes and needs. Also, we need to have at least half of Sunday available, so that we can re-consider our ideas over night, and don't need to make decisions in a rush. In case we are going to do that, I'd look if I can get some Debian-friendly "upstream" person who is not involved yet for a second opinion. If I should follow on that, please tell me. I already spoke with Steve, we can use Debian ressources (i.e. money) for that. (If you think this wouldn't help please say as well - that'd save us all the effort of the meeting.) Cheers, Andi

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Thu, 18 Mar 2010 20:06:06 GMT) (full text, mbox, link).

Acknowledgement sent to Piotr Ożarowski <piotr@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Thu, 18 Mar 2010 20:06:06 GMT) (full text, mbox, link).

Message #30 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Piotr Ożarowski <piotr@debian.org> To: 573745@bugs.debian.org Subject: Re: Bug#573745: Please decide on Python interpreter packages maintainership Date: Thu, 18 Mar 2010 21:03:28 +0100

[Andreas Barth 2010-03-18] > I agree. I tried to get one such meeting done some time ago (see > below) Here's my reply from that thread (Matthias or DPL never responsed, or at least I wasn't in the loop) [Piotr Ożarowski, 2009-09-27] > Adding Raphael Hertzog to Cc as he knows the beginning of py{central,support} > saga much better that I do and IMO always tries to find a consensus > instead of arguing till death :-) > > > as part of the recent release mails, we got some - well, "complaints" is > > the wrong word, but definitly in that direction - mails about python2.6 (or > > rather its inexistence in unstable). > > Debian's Python situation is not perfect indeed. I don't know if it was > better in the past - when I joined Debian few years ago it was already > one big minefield[1] which doesn't help maintaining Python packages / > recruiting new developers. > > [1] outdated Debian Python Policy (no consensus about what it should > contain), unwritten rules, 3 different (mostly undocumented) helper > tools, python maintainer not really active (yes, even then, see > reasons for founding DPMT), cdbs not supporting these new tools at > all (dh didn't exist at that time), maintainers forced to do lots of > work in debian/rules in order to satisfy not existing policy, ... > > Let me shortly describe the situation from my perspective (i.e. from a > person who don't know much about what happened in Mexico). > > I started with dh_pysupport (which was the only tool available in > unstable, except dh_python) but switched most of my packages (not all) > to dh_pycentral really soon after that as I thought it was better > designed - it supported Python extensions and didn't provide additional > problems with __file__ and namespace issues (i.e. it stored .pyc files > where everybody expected them to be). After a while, dh_pysupport > started to be more and more mature (Python extensions support, bugs > fixed really fast, additional features like Egg renaming, namespace > (re)generation[2], etc.) and pycentral didn't change much and when it > did change, it broke lots of packages by some internal changes never > announced to anybody. > > [2] IIRC, this was the only change not really well announced/tested and > with wrong (see #459468) defaults in pysupport > > So I took advantage of the fact that nobody really sponsored Python > packages[3] and that many DDs (who were my sponsorees in the past or > whom I helped with some Python related problems) trusted me and decided > to get rid of one of the tools: python-central. And it worked fine, lots > of packages were converted in the last few months. > > [3] see [1] for possible reasons > > Then, after I talked with Matthias (on my first DebConf) and realized > that he will not upload python2.6 until we'll fix the helpers issue once > and for all - I tried to pick up one of his ideas - symlinks (it's > almost perfect solution - the only real problem is the fact that > arch:all packages needs to be rebuilt once list of supported Python > version changes), try to adjust it a little bit (f.e. remove his pet - > "current" keyword), and if it will be accepted - update official Debian > Python Policy... > > That didn't work that well. Surprisingly many developers didn't like the > idea and didn't even want to discuss it[4] and Joss is obviously not > interested in changing status quo as status quo means removing > python-central at some point (so far only Scott didn't want to convert > his packages to python-support, it was very easy to convince other > maintainers - the longest conversation I had was the one with Martin > Krafft - and he just wanted to know why I want to convert his packages, > didn't object much about dropping pycentral). > > [4] I thought we could find a workaround for arch:all binNMUs issue, maybe > some kind of semi-automatic rebuilds that do not suffer from binNMUs > problems... > > > Here's what we plan to do in the near future and what can eventually be > discussed in such meeting (I'm not really sure that such meeting will > change much if both Joss and Matthias will not tell us they're willing > to hear others arguments and make a compromise). > > We are fixing current tools and packages to support changes introduced > in python2.6 which is currently in experimental: > * http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-python@lists.debian.org;tag=python2.6 > * cdbs will go to unstable today (I uploaded NMU to DELAYED/7 a week ago) > * I will attach a fix to python-central today or tomorrow > > and then we will add 2.6 to supported versions in NMUs (I will upload > it, I'm so sick of the current situation that I will rather let Matthias > remove my key from Debian keyring than release Squeeze without 2.6 or > force us to do the transition 1 month before the release, like in > Ubuntu). > > If my NMU will be rejected, I plan to hijack python and try to maintain > it in a team of few DDs (don't worry, I'll ask before the hijack, not > after - if nobody will be interested, I will not maintain it alone - > that would make it only worse) - I really don't want this to happen as > Matthias is probably the one who knows more than anyone else about > maintaining Python. I already took a quick look at python bugs to see if > I'm able to fix them. I saw many easy to fix bugs (time consuming, but > easy to fix) or even bugs that are not bugs at all (Python developers > would call them "features" or user broke his system with local > modifications). So... > > Matthias *needs* co-maintainers! Looks like he tries to respond to > serious problems (f.e. he dealt with recent libdb issue) but doesn't > have time at all to process other, less urgent ones. > > I will start proposing NMUs to these bugs (patches are not enough, see > BTS) and if Matthias will like them, at some point I will propose to > accept me as co-maintainer, if not, he'll have proves that he needs one > and I'll try to force him to choose another one. > > Anyway, IMHO what can be discussed in such meeting is what can we do > after the Python 2.6 transition: > * try to fix my dh_python proposal and implement it, or > * remove python-central completely and let python-support use > /usr/lib/python*/*-packages (i.e. official places, without the need to > use .pth files) and keep using /usr/{share,lib}/pyshared to ship > .py/.so files, or: > * 3rd solution, perfect one this time (its author is waiting for a > perfect timing to hit us with it when we'll not expect it ;) > -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Thu, 18 Mar 2010 21:33:02 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Thu, 18 Mar 2010 21:33:02 GMT) (full text, mbox, link).

Message #35 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org> To: 573745@bugs.debian.org Subject: Re: Bug#573745: Please decide on Python interpreter packages maintainership Date: Thu, 18 Mar 2010 22:31:03 +0100

* Piotr Ożarowski (piotr@debian.org) [100318 21:09]: > [Andreas Barth 2010-03-18] > > I agree. I tried to get one such meeting done some time ago (see > > below) > > Here's my reply from that thread (Matthias or DPL never > responsed, or at least I wasn't in the loop) The DPL was only in the loop "for information". He already agreed to a meeting if it's useful, or basically anything we as group considered useful. So I didn't expact any answer either, unless we would have ask specifically for details of travel sponsorship for a meeting or so. Andi

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Mon, 22 Mar 2010 18:54:03 GMT) (full text, mbox, link).

Acknowledgement sent to Luca Falavigna <dktrkranz@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Mon, 22 Mar 2010 18:54:03 GMT) (full text, mbox, link).

Message #40 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Luca Falavigna <dktrkranz@debian.org> To: 573745@bugs.debian.org Cc: doko@debian.org, leader@debian.org Subject: Re: Bug#573745: Please decide on Python interpreter packages maintainership Date: Mon, 22 Mar 2010 19:50:32 +0100

Hello, we apologize for the delay in our reply. On Wed, Mar 17, 2010 at 23:50, Bdale Garbee <bdale@gag.com> wrote: > On Sat, 13 Mar 2010 17:24:51 +0100, Sandro Tosi <morph@debian.org> > wrote: >> Package: tech-ctte >> Severity: normal >> >> Hello Technical Committee, >> we'd like you to decide about how the Python interpreter packages >> should be maintained in Debian. > > I've spent several hours since my last message communicating with the > current Python maintainer, reading various mailing list threads and > bug logs, and generally trying to understand the situation as best I > can. Thanks a lot for your investment on this matter. It can be quite time-consuming since, as you noted, things can get pretty emotional. It is sad, though, that this discussion happened in private. We can understand the general reason, but we think having minutes of what was discussed would be interesting to have reported here. Part of the problem is that Matthias is not communicating anymore on public channels, and uses other people as a proxy. To start on solid bases, it would be good if we didn't repeat the same errors from the past. A large part of the perceived issues are directly related to lack of communication, and one of the reasons for our request is 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. Of course, we respect the privacy of those conversations, so we also understand if you're going to decide to keep them private. In any case, if some points arose from those dialogues that you may want us to give examples (or counter-examples), we'd be more than happy to provide them to you. > It bothers me that what you've brought to the TC is a rant about your > frustrations culminating in a request to remove someone else from > their role, rather than a crisper articulation of what's wrong and a > plan that explains how we should move forward. We are sorry if it sounded that way, because this is not the message we wanted to convey. We tried to list the current issues from a technical point of view, and if you want us to elaborate on a specific point, we’ll be happy to provide more input. Overall, our request indeed lacks a complete plan of what we want to implement; because it is not about what should be implemented, but about how it should be discussed, elaborated and coordinated. That said, we understand that you want us to explain what we would propose and implement if we were maintainers for Python, so we will try to elaborate on that. It is not that easy because we have no clear idea of what the current plans of the Python maintainer are. As for removing the current maintainer from his position, it is only one of the possible solutions. We do think that such a core package cannot be effectively maintained by a single person, also given the other points we made in the original email, and that a team should be formed around it. If the current maintainer would like to be part of it, he's very welcome, but at least he should be willing to collaborate; his past actions make us dubious about this, but we are open-minded and hoping for a positive resolution. We were told (again, in private) than one of the proposed members for the team (namely Joss) is a showstopper for Matthias to be part of the said team. We don’t find it a reassuring perspective that Matthias is putting his personal feelings before the best interest for Python in Debian. It was hard for Joss to propose to work together with him given their history, and we’d find it better if everyone involved could make similar efforts. However, if it is required for things to go forward, Joss agreed to step back from the team as a last-resort solution. > In my reading and discussion with > others, there are hints about different agreements at different times > between different people about how to handle various transitions, but > as someone not party to the various discussions over time, I wish I > could find a single, well articulated policy for Python in Debian. > There are more people I want to talk to, and perhaps one or more of > them will make everything clear to me... but I do not want to delay > things further. For a long period of time, the only document that was approaching a Python policy was the complete rewrite initiated by Manoj. The Python policy itself remained incorrect until the upload of python-defaults 2.5.4-4, which brought it mostly on par with the current practice. Let us state it out loud: this was a huge achievement, and we're happy something has moved in the right direction; but please also note that the updated process was not lead by the current Python maintainer, but from (at that time) and external person, that only after his work gained the status of co-maintainer of python-defaults. However there are some points of strong disagreement that remain even in that current policy (not talking about the future), and because of that, maintainers of Python packages don’t all work the same way: * There is no consensus on use of the XS-Python-Version header. The Python maintainer promotes a "current" keyword, which several people think has no semantical value. * There is no consensus on what should be in the Provides header. The policy promotes systematically adding pythonX.Y-foo to this field, which leads to incorrect dependencies being generated. There are some alternate solutions, unfortunately none of which is completely satisfactory. > I realize this may not be what you had in mind when you asked the TC > to "decide about how the Python interpreter packages should be > maintained in Debian", but now that you've opened Pandora's box, I > believe we have a responsibility to understand the underlying > problems that apparently have plagued Python policy for years, so > that whatever decision we take will ensure the most positive outcome > for Python handling in Debian in the future. This is somehow reassuring that the technical committee tries to understand underlying technical issues. Thank you for making this technical and trying to resolve this situation, that's really appreciated. > I'm adding the DPL to this reply because it seems possible that the > only way to achieve this objective might be an in-person Debian > Python Summit meeting, moderated by members of the TC, where we can > work through all the issues and come to consensus. Perhaps we can > resolve our problems by email and/or IRC, but the mere existence of > this petition to the TC and what it implies about communication > disconnects makes me doubt that. Andreas already proposed such a face-to-face summit a few months ago, but ended up abandoning the idea for the moment. This could be the way forward, but it would also be extremely tiring, in an emotional way. Some of the human issues around Python packaging started with a face-to-face meeting that turned out very badly at Debconf 6. > Before I'll be willing to support any Technical Committee action on > this petition, I believe we need a detailed and competent plan > articulated, that explains how we get from where we are today to a > single policy for Python in Debian, and that covers at least: > > 1) our philosophy for handling multiple Python interpreter versions > 2) the supported approach(es) to packaging Python modules > 3) an analysis of the effort involved and who needs to do what > 4) a tentative schedule of milestones to completion, including what > can and should be done before squeeze freeze > 5) explicit commitment by involved parties to do the required work Well, this is one of the points for which the Technical Committee might have to make decisions, since there are strong disagreements in how Python modules should be managed in the future. There are also even stronger disagreements over what parts of it should go into Squeeze. We can try to sum up these disagreements from our point of view if you find it useful. In order to provide some technical background to the petition, and as an example of how we would handle a future similar situation, we'd like to present here what we (as the debian-python community) have done to prepare and support the Python 2.6 transition, to which the current Python maintainer is sadly not participating in any practical standpoint. - We provided impact analysis (packages in need of binNMUs or sourceful uploads) for the 2.6 introduction in the supported python versions and conducted an archive-wide rebuild. - We did the same for the python2.4 removal when Matthias suddenly decided to remove it as well. - We provided patches for debhelper, cdbs, python-central and python-support to support the dist-packages transition. - We asked to schedule more than 150 binNMUs (http://people.debian.org/~dktrkranz/python2.6/python2.6_binNMUs), following their progress, and filing/fixing bugs as they came out or requesting give-backs as needed. - We filed 282 bugs (http://tinyurl.com/Py26Transition) to support the transition, of which 90% is already closed or waiting for an upload. If we consider the python2.4 removal too, this bug count rises to 345. - We made many team uploads, where we uploaded the packages in the Python Modules or Apps team to support the transition. - We prepared NMUs for those bugs, either as direct NMUs or sponsored ones. - We provided help to people who contacted us about how to setup a test environment or how to properly fix their packages for the transition. - We were supported by the Release Team (in the person of Andreas Barth, many thanks!) in the binNMUs part, and we were asked to provide impact analysis for the 2.6 switch as default in unstable (as part of the pre-freeze Release Team plan), showing that with our previous activities we have gained credibility in the eyes of the Release Team. - We asked for a partial-archive wide rebuild to test the impact of setting Python 2.6 as default and filed bugs accordingly. >> transitions to force some controversial, unrelated technical >> changes to be implemented before these transitions happen. > > I think this is a key part of the problem. The Python maintainer does > not seem to believe that these are unrelated technical issues. And > the controversy that does exist seems now to be more fueled by a > combination of emotion and inertia than technical concerns. We need > to get past that, and focus our attentions squarely on a good Python > technical policy and associated implementation plan. I think > everything else will flow fairly easily if we can accomplish that. We don’t think it is enough to know where we are going. We also need to know how to get there and how it integrates in the release process. For example, the dist-packages migration solves a problem most people agreed on (local module installations not going to /usr/local). However, not only was the implementation not discussed (we could have worked on an implementation implying less burden on python modules maintainers), but it was bound to the introduction of python2.6, and it delayed the migration to this version, which otherwise would have been a matter of weeks (unlike 2.4→2.5, the 2.5→2.6 upgrade doesn't require any changes to existing sources). Furthermore, the strategy for handling Python modules can have a strong impact on the release schedule. For example, if we want to change for the better the way modules are handled in the future, we need the following: * expose possible strategies - we are barely here yet; * reach consensus on the best solution; * implement whatever needs to be implemented; * make packages transition - depending on the solution, this can take a lot of time, some of the solutions requiring sourceful changes to all Python packages. It was completely unrealistic to be able to do that before the squeeze release, and it became even more unrealistic over time when even the first item was not dealt with. Yet Matthias wants these changes implemented before python2.6 to be introduced in unstable. This is now putting the release schedule at risk, since we don’t have much time before the freeze (and the Release Team already made us a big gift granting us 1 months for the transition in the pre-freeze plan), and it is not reasonable to release without Python 2.6 being the default - at least, our users wouldn't understand. This is the key point of our request to the Committee. We have no problem with packaging changes, but at the following conditions: * they must be discussed with other maintainers of Python modules; * they must make things better for our users; * they should not have a too big impact on the rest of the distribution. Therefore, we want to maintain the Python packages and implement such changes, but only with consensus from the community and using open methods. In the specific case that is being discussed currently, we think the packaging changes - if they are needed - need to be postponed after the python2.6 transition. We can start to discuss and implement things before the freeze, but we think it’s too late to start a transition now. Said otherwise, the "python2.6 as default" and "change everything in the way to package Python modules" transitions need to be handled separately and sequentially. This is also the usual way the Release Team likes maintainers to work. Furthermore, the specific changes that have been proposed are high risk, and several questions need to be answered before the transition can be considered. - How will the new helper be used? As a drop-in replacement or something different? - Will it replace any of the existing helpers? If yes, which and how? - Will the maintainers using the removed helpers be forced to use the new one? - How will we ensure the correct behavior of the new helper in all the archive? - Are there any functional regressions? - And more importantly than anything else, where is the policy document that specifies the implementation? These are the questions that would have arisen automatically, had the proposal been discussed openly within the Debian/Python community. And we would have answers instead of being in the blue. Kind regards. Luca, Josselin, Sandro, Bernd

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Wed, 24 Mar 2010 10:54:03 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 24 Mar 2010 10:54:03 GMT) (full text, mbox, link).

Message #45 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org> To: 573745@bugs.debian.org Subject: Re: Bug#573745: Please decide on Python interpreter packages maintainership Date: Wed, 24 Mar 2010 11:52:12 +0100

* Bdale Garbee (bdale@gag.com) [100318 00:00]: > It bothers me that what you've brought to the TC is a rant about your > frustrations culminating in a request to remove someone else from their > role, rather than a crisper articulation of what's wrong and a plan that > explains how we should move forward. In my reading and discussion with > others, there are hints about different agreements at different times > between different people about how to handle various transitions, but as > someone not party to the various discussions over time, I wish I could > find a single, well articulated policy for Python in Debian. There are > more people I want to talk to, and perhaps one or more of them will make > everything clear to me... but I do not want to delay things further. I want to send my current thoughts to this list - this is just "work in progress". Speaking with people takes time, but is necessary for a good solution. This conflict has its root way in the past, and has been escalating for quite some time till it reached the tech ctte. So I want to find not only an solution for the current request, but I want to find a way how we can avoid to see yet another instance starting in a few months, starting to make more and more people unhappy, and then accumulating to the tech ctte again in 2-3 years. My goal is to make sure the debian python community is fun again for the people involved, less frustrating, and can deal with the usual disagreements (that of course exist when people do stuff together) without external help or escalations. Also this means that we will probably need to review how it works in another 6 months, and reserve the right to change things as necessary then. My other goal obviously is to get the python 2.6 transition done in a way that doesn't block the release, and do it in time for the release. :) So, together this seems to indicate (order might be wrong, sorry, this is just a braindump): 1. Establish co-maintainers for python (including pythonX.Y) that both the community and the current maintainers are ok-ish with. 2. Get a final common (or at least accepted) technical decision how to resolve the lingering technical issues that Bdale spoke about. This involves sorting out with upstream. This also involves decisions which parts needs to be done prior to squeeze, and which not - and then picking up the stuff "after squeeze" really after squeeze is done). 3. Establish a conflict-resolution mechanismn inside of the debian python community that is accepted by all involved parties, where decisions are not questioned on afterwards again, where people are actively working with (or at least not blocking or working against decisions), and which makes sure we go in the same directions as upstream. (This is probably a pre-condition to get 2. done.) (Of course, we also need to set a few things about "what can and what can't this mechanismn resolve".) 4. We need to get a list of current open technical conflicts, and then probably add some dates when we want to have what resolved (of course dates can be changed, but we need to have some criteria to see "oh this works" or "that doesn't work" - could also be something like "from the 5 issues we want to have at least 3 sorted out till $time after release of squeeze"). So far for now. Now I need to have more talks with more people. Andi

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Thu, 25 Mar 2010 14:03:06 GMT) (full text, mbox, link).

Acknowledgement sent to Scott Kitterman <scott@kitterman.com> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Thu, 25 Mar 2010 14:03:06 GMT) (full text, mbox, link).

Message #50 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Scott Kitterman <scott@kitterman.com> To: 573745@bugs.debian.org Subject: Python Policy Update Date: Thu, 25 Mar 2010 09:59:46 -0400

> Let us state it out loud: this was a huge achievement, and we're > happy something has moved in the right direction; but please also note > that the updated process was not lead by the current Python maintainer, > but from (at that time) and external person, that only after his work > gained the status of co-maintainer of python-defaults. Since I'm that person, I'll comment on this. First, I think it would have been silly to do a python-defaults upload just to add me to uploaders. There was no point in uploading it until there was some worthwhile technical content to upload, so the entire business about being an external person is odd at best. Second, due to the unfortunate social history in Debian Python it was my belief then and now that the same policy update would have failed if Matthias were the lead for it. It would be a mistake for anyone who didn't see all the various inputs to the update to make any assumptions about how much of the update was or was not influenced by any particular person. I know a lot of people don't like that much of the communication was in private, but I think it's better to have the update that we now have than to continue the previous gridlock. With respect to: > * There is no consensus on use of the XS-Python-Version header. The > Python maintainer promotes a "current" keyword, which several people > think has no semantical value. This is resolved. The current Python Policy says: > The keyword "current" has been deprecated and used to mean that > the package would only have to support a single version (even > across default version changes). It would be useful if the discussions about disagreements would focus on issues that have not already been resolved. Scott K

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Thu, 25 Mar 2010 22:27:04 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Thu, 25 Mar 2010 22:27:04 GMT) (full text, mbox, link).

Message #55 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org> To: 573745@bugs.debian.org Subject: Re: Bug#573745: Python Policy Update Date: Thu, 25 Mar 2010 23:24:21 +0100

* Scott Kitterman (scott@kitterman.com) [100325 15:05]: > It would be useful if the discussions about disagreements would focus on > issues that have not already been resolved. Agreed. Also, I think that the updates to the python policy are an good example how we could move on. Thank you for doing so. Andi

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Wed, 31 Mar 2010 10:51:05 GMT) (full text, mbox, link).

Acknowledgement sent to Arnaud Fontaine <arnau@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 31 Mar 2010 10:51:05 GMT) (full text, mbox, link).

Message #60 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Arnaud Fontaine <arnau@debian.org> To: 573745@bugs.debian.org Subject: Re: Please decide on Python interpreter packages maintainership Date: Wed, 31 Mar 2010 12:38:13 +0200

Hi, As shown clearly in the past years, Python cannot be maintained by a single developer, so I do think it should be maintain within a team to allow fixes and new versions of upstream Python to be pushed quickly. Therefore, I strongly second Sandro proposition. Regards, Arnaud Fontaine

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Tue, 11 May 2010 21:12:03 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Tue, 11 May 2010 21:12:03 GMT) (full text, mbox, link).

Message #65 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org> To: 573745@bugs.debian.org Subject: python maintainance: next steps Date: Tue, 11 May 2010 23:08:08 +0200

Hi, sorry for not updating this request for such a long time - but things take longer than I'd like them to take. However, there have been some talks within the tech ctte and with different people inside the Debian python community. That needed time, and we prefer to get to a resolution a bit later than to one that doesn't work. I doubt we can get to a final decision as of now. The complaints are mostly non-technical. Re the technical parts, e.g. the discussion within Debian about "where to store files" brought two upstream proposals (PEPs) which would fix some disagreements in an good and forward way. I don't want to loose Matthias contributions to python within Debian and the python community. The complaints are that the people in the Debian Python Community aren't enough involved in the decisions, and especially feel "left in the cold" re when to expect things to happen (or what are the reasons why they don't happen). The transition to use version 2.6 of python as default is just an example for most people involved (and was the reason finally the tech ctte was called in, but definitly not the only conflict). Parts of the conflicts date many years back, as well as the inability of some people to work together. The discussions have especially lead us to the conclusion that a team with both Matthias and Joss involved won't work. All in all, the situation isn't easy. Not easy for Matthias, not easy for anyone else and not easy for the technical committee. Please understand that our task isn't to decide who to blame for the current situation. Our task is to make sure that we can go to a better future. Probably our decision won't be totally fair and nice to all people involved. I can only say for my part that I try to be as fair and nice as possible, but an working solution is even more important. It's not about fault, it's about a good future. So, where does that leave us? We need to establish an mechanismn that could resolve such conflicts before they can grow so large for years. We also need to have more people in the python packages maintainer field. We need to try to keep as many of our python people involved as sanely possible. In order to be able to get things going within the python community, we should establish a python core team that is trusted by all people involved. "Trusted by all people involved" definitly includes trusted by Matthias as current python maintainer, and trusted by the people who signed the request to the technical committee (of course, in worst case I'm willing to just decide on the membership of the core team). (There is an obvious conclusion who can't be member of the core team.) I think it would be good if at least one person (better two) in that team knows enough about python upstream to make sure Debian and upstream evolve in the same direction. That team would also be the arbiter about disagreements re the debian python policy. Obviously derivations from upstream shouldn't happen easily, so I think there should be precautions that they happen without very good reason. Anyways, the first task of the core team would be to settle an decision policy. That policy needs also to include rules how the core team membership changes. Re the python packages maintainership, I propose to ask Matthias to get at least two more people involved who are ok for the python core team. We should revisit how this works anyways after some time (e.g. in 6 months). In case we don't have two co-maintainers for the python packages in reasonable time, we also reserve the right to make a decision with names in it (we could do that anyways, but we should explicitly say so). So far for now. Comments? If the tech ctte agrees with this proposal, our next steps are: 1. discuss/decide who is part of the python core team 2. establish an conflict solution proposal 3. having two more python maintainers added which are ok to the core team After that, watch the situation for some reasonable amount of time, and review it when it's sane to do so (e.g. 6 months later). Andi

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Wed, 12 May 2010 15:27:03 GMT) (full text, mbox, link).

Acknowledgement sent to Josselin Mouette <joss@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 12 May 2010 15:27:03 GMT) (full text, mbox, link).

Message #70 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org> To: 573745@bugs.debian.org Subject: Re: python maintainance: next steps Date: Thu, 13 May 2010 00:24:20 +0900

(Note: this email expresses my personal opinions only, not those of the other proponents.) Le mardi 11 mai 2010 à 23:08 +0200, Andreas Barth a écrit : > However, there have been some talks within the tech ctte and with different > people inside the Debian python community. That needed time, and we prefer > to get to a resolution a bit later than to one that doesn't work. I doubt > we can get to a final decision as of now. First of all I’d like to express my sadness to see these discussions, again, having being conducted privately. We have now several years behind us that show this is a bad idea, and the CTTE, asked to resolve this matter, chose to adopt the same technique. > The complaints are mostly non-technical. Re the technical parts, e.g. the > discussion within Debian about "where to store files" brought two upstream > proposals (PEPs) which would fix some disagreements in an good and > forward way. You shouldn’t be too optimistic about the upstream proposal, since it only allows to do a tenth of the needed job. There’s a huge work remaining if we want to drop the symlink farms, starting with dealing with a way to handle which versions are supported by which file. > I don't want to loose Matthias contributions to python > within Debian and the python community. This is completely irrelevant, unless Matthias threatened to stop contributing unless he can keep setting the rules. But I know the CTTE wouldn’t take such “don’t touch my garden” blackmail into account, of course. > In order to be able to get things going within the python community, we > should establish a python core team that is trusted by all people involved. > > "Trusted by all people involved" definitly includes trusted by Matthias as > current python maintainer, and trusted by the people who signed the request > to the technical committee (of course, in worst case I'm willing to just > decide on the membership of the core team). (There is an obvious conclusion > who can't be member of the core team.) > So far for now. Comments? It means giving a veto power to Matthias about who can or cannot contribute, while not giving this power to others. Which really, really doesn’t make much difference with a situation where he can decide alone which contributions can go in. I think that practically speaking, it won’t change a thing. Oh, a completely unrelated comment: it looks to me that the Python 2.6 transition is going to delay the squeeze freeze date. Anyone has some pop-corn? -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `- […] I will see what I can do for you.” -- Jörg Schilling

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Wed, 12 May 2010 21:33:17 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Wed, 12 May 2010 21:33:17 GMT) (full text, mbox, link).

Message #75 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org> To: 573745@bugs.debian.org Subject: Re: Bug#573745: python maintainance: next steps Date: Wed, 12 May 2010 23:28:46 +0200

* Josselin Mouette (joss@debian.org) [100512 17:27]: > Le mardi 11 mai 2010 à 23:08 +0200, Andreas Barth a écrit : > > However, there have been some talks within the tech ctte and with different > > people inside the Debian python community. That needed time, and we prefer > > to get to a resolution a bit later than to one that doesn't work. I doubt > > we can get to a final decision as of now. > > First of all I’d like to express my sadness to see these discussions, > again, having being conducted privately. We have now several years > behind us that show this is a bad idea, and the CTTE, asked to resolve > this matter, chose to adopt the same technique. So you think the only acceptable option is to take away the maintainership from Matthias? And even if we would do that, how can we be sure that this resolves all the issues we have? > > I don't want to loose Matthias contributions to python > > within Debian and the python community. > > This is completely irrelevant, unless Matthias threatened to stop > contributing unless he can keep setting the rules. But I know the CTTE > wouldn’t take such “don’t touch my garden” blackmail into account, of > course. I would expect that deciding to remove him from being maintainer would demotivate him - at least that would be a natural thing to happen. > It means giving a veto power to Matthias about who can or cannot > contribute, while not giving this power to others. Eh, where does that proposal give Matthias veto power? Andi

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Thu, 13 May 2010 01:09:03 GMT) (full text, mbox, link).

Acknowledgement sent to Josselin Mouette <joss@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Thu, 13 May 2010 01:09:03 GMT) (full text, mbox, link).

Message #80 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org> To: 573745@bugs.debian.org Subject: Re: Bug#573745: python maintainance: next steps Date: Thu, 13 May 2010 09:58:19 +0900

Le mercredi 12 mai 2010 à 23:28 +0200, Andreas Barth a écrit : > > > I don't want to loose Matthias contributions to python > > > within Debian and the python community. > > > > This is completely irrelevant, unless Matthias threatened to stop > > contributing unless he can keep setting the rules. But I know the CTTE > > wouldn’t take such “don’t touch my garden” blackmail into account, of > > course. > > I would expect that deciding to remove him from being maintainer would > demotivate him - at least that would be a natural thing to happen. This line of reasoning is fallacious. I could reverse it and talk about people who are demotivated because they feel the current maintainer is incompetent. How could this help guiding the decision? > > It means giving a veto power to Matthias about who can or cannot > > contribute, while not giving this power to others. > > Eh, where does that proposal give Matthias veto power? If Matthias can refuse someone to be part of the core team because he doesn’t trust that person, that’s a veto power. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `- […] I will see what I can do for you.” -- Jörg Schilling

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Thu, 13 May 2010 09:21:05 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Thu, 13 May 2010 09:21:05 GMT) (full text, mbox, link).

Message #85 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org> To: debian-ctte@lists.debian.org Subject: Re: Bug#573745: python maintainance: next steps Date: Thu, 13 May 2010 11:15:41 +0200

* Josselin Mouette (joss@debian.org) [100513 03:09]: > Le mercredi 12 mai 2010 à 23:28 +0200, Andreas Barth a écrit : > > > > I don't want to loose Matthias contributions to python > > > > within Debian and the python community. > > > > > > This is completely irrelevant, unless Matthias threatened to stop > > > contributing unless he can keep setting the rules. But I know the CTTE > > > wouldn’t take such “don’t touch my garden” blackmail into account, of > > > course. > > > > I would expect that deciding to remove him from being maintainer would > > demotivate him - at least that would be a natural thing to happen. > > This line of reasoning is fallacious. I could reverse it and talk about > people who are demotivated because they feel the current maintainer is > incompetent. How could this help guiding the decision? Don't you see that we want to end that? > > > It means giving a veto power to Matthias about who can or cannot > > > contribute, while not giving this power to others. > > > > Eh, where does that proposal give Matthias veto power? > > If Matthias can refuse someone to be part of the core team because he > doesn’t trust that person, that’s a veto power. For the initial setup, I would like to have people in the core team that are ok by both Matthias and the people who brought this to the tech ctte (e.g. you). If that doesn't work out, we'll of course decide who is in the core team. I think that's reasonable. For further changes, it's the task of the core team to setup an procedure how to do that. Andi

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Thu, 13 May 2010 14:09:06 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Thu, 13 May 2010 14:09:06 GMT) (full text, mbox, link).

Message #90 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org> To: 573745@bugs.debian.org Subject: Re: Bug#573745: python maintainance: next steps Date: Thu, 13 May 2010 16:04:00 +0200

* Ian Jackson (ijackson@chiark.greenend.org.uk) [100513 15:22]: > I think we do need to consider whether it would be best if the > maintainer put their evident technical skills to use elsewhere. Not > just in the context of one package, but also to so that the project > can see that if you really can't manage to work with people, and act > as a blocker, you may be deposed. Obviously that's true. For me, I'd try to get things changed without using our (existing) overruling capabilities. If it works, good. If not, we'll of course *have* to just put in other names. Andi

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Fri, 21 May 2010 14:48:03 GMT) (full text, mbox, link).

Acknowledgement sent to Sandro Tosi <morph@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Fri, 21 May 2010 14:48:03 GMT) (full text, mbox, link).

Message #95 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Sandro Tosi <morph@debian.org> To: Andreas Barth <aba@not.so.argh.org>, 573745@bugs.debian.org, debian-ctte@lists.debian.org Subject: Re: Bug#573745: python maintainance: next steps Date: Fri, 21 May 2010 16:44:54 +0200

Hello, thanks for the update, and sorry for this late reply. On Tue, May 11, 2010 at 23:08, Andreas Barth <aba@not.so.argh.org> wrote: > sorry for not updating this request for such a long time - but things take > longer than I'd like them to take. we understand that it's not an easy task, involving several sub-activities. Please also understand that not receiving any update could give the impression that nothing is being done (that turned out it's not this case, but still), so a periodic update like "we're still talking to people, don't worry we're working on it" it's important. > However, there have been some talks within the tech ctte and with different > people inside the Debian python community. That needed time, and we prefer > to get to a resolution a bit later than to one that doesn't work. I doubt > we can get to a final decision as of now. > The complaints are mostly non-technical. Re the technical parts, e.g. the > discussion within Debian about "where to store files" brought two upstream > proposals (PEPs) which would fix some disagreements in an good and > forward way. I don't want to loose Matthias contributions to python > within Debian and the python community. Please let us reaffirm our "complains" are also technical: try not put them aside just dealing with the personal situations around Python. In several occasions (even recently) there were situations we can mention to challenge the "technique" (either being the pure packaging technicalities, or the attention/interest dedicated, or more); we don't want to point fingers directly to those mistakes, but let's not reduce this tech-ctte call to only feelings. Talking about Python upstream, even if Matthias' contributions are currently quite limited (but still present, and we thank him for that) we feel they are done using his Canonical-employee hat (for example, a recent email[1]), so not much a direct consequence of him being a DD or the Debian maintainer; also note that both those PEPs (and we share the believe they are a move forward) were not driven by Matthias (he only reviewed them) so it's not holding that much your sentence. [1] http://mail.python.org/pipermail/python-dev/2010-May/100183.html Additionally, "Matthias contributions to python within Debian" are exactly what we are challenging here, and they are at the very least "debatable" (to not say "close to nothing" or "harmful for the Debian project"). > The complaints are that the people in the Debian Python Community aren't > enough involved in the decisions, and especially feel "left in the cold" re > when to expect things to happen (or what are the reasons why they don't > happen). The transition to use version 2.6 of python as default is just an > example for most people involved (and was the reason finally the tech ctte > was called in, but definitly not the only conflict). > Parts of the conflicts date many years back, as well as the inability of > some people to work together. The discussions have especially lead us to > the conclusion that a team with both Matthias and Joss involved won't work. We only would like to highlight again how we believe Joss is a very highly technically skilled DD, and how his contributions to the Python packages have been, and will be, profitable to the project. We understand there are other reasons that forbid to create a team including both Matthias and Joss, though. > All in all, the situation isn't easy. Not easy for Matthias, not easy for > anyone else and not easy for the technical committee. Please understand > that our task isn't to decide who to blame for the current situation. Our > task is to make sure that we can go to a better future. Probably our > decision won't be totally fair and nice to all people involved. I can only > say for my part that I try to be as fair and nice as possible, but an > working solution is even more important. It's not about fault, it's about a > good future. We know, and appreciate that. > So, where does that leave us? We need to establish an mechanismn that could > resolve such conflicts before they can grow so large for years. We also > need to have more people in the python packages maintainer field. We need > to try to keep as many of our python people involved as sanely possible. > > In order to be able to get things going within the python community, we > should establish a python core team that is trusted by all people involved. > > "Trusted by all people involved" definitly includes trusted by Matthias as > current python maintainer, and trusted by the people who signed the request > to the technical committee (of course, in worst case I'm willing to just > decide on the membership of the core team). (There is an obvious conclusion > who can't be member of the core team.) As already pointed out by Joss in another email, is Matthias being granted with a veto vote? Can he indefinitely veto people willing to join such team even if others are OK with them? If that's the case, we believe this simply won't work and would kill democracy. It seems you are trying to please Matthias very much, that's nice, but what are the assurances you received he will behave differently from now on? The fact that he didn't write a single word here makes us quite skeptical if things will ever change. We are unaware of the discussion you had with Matthias, but disclosing it is a core point of the problem at hand, and always raising the "privacy wall" can't the way to go. Situations likes this one happened and will happen again (sadly), and the resolution of this case will be an example case on how such things will be handled: we have the occasion here to show how Debian acts in situation where there is some real disagreement in package maintenance. We can pass the message that no matter how you maintain your packages, no matter how badly you behave with your peers, no matter what you do, you'll be grant forgiveness, and we'll pretend all of these never happened and you'll be left in an advantage position over maintaining your packages (even for the fear of possible repercussions in other activities for Debian). Or we can pass the message that we are a community (and not just a bunch of geeky people) and we must act like one, so if you're deliberately screw with your peers because you don't care for them, if you feel so superior to them that you're not going even to speak to them, if your interest in packages maintenance is so low and several times you've uploaded "half-beaked" packages failing even the basic pre-upload tests (like installing them) then we'll bring the packages back to the community, where they belong to, and given in hands proven to caring for them. In this spirit, we'd like to emphasize Ian's reply to this thread. > I think it would be good if at least one person (better two) in that team > knows enough about python upstream to make sure Debian and upstream evolve in > the same direction. We recently saw Barry Warsaw more involved, which is very positive. We don't know if you already contacted him, or if he would accept, but he would be a good candidate, especially one who doesn't have a history in Debian. > That team would also be the arbiter about disagreements re the debian > python policy. Obviously derivations from upstream shouldn't happen easily, > so I think there should be precautions that they happen without very good > reason. > > Anyways, the first task of the core team would be to settle an decision > policy. That policy needs also to include rules how the core team > membership changes. > > Re the python packages maintainership, I propose to ask Matthias to get at > least two more people involved who are ok for the python core team. So are you proposing to form the Python core team as an entity separated from the Python maintainers? Like an entity supervising the activities of Python maintainer? We are not criticizing the idea, it's just to understand the proposal. If that's the case, what are the powers of this team over the Python maintainers? Can the core team force maintainers to implement something or fix a given bug? If so, how, and with which powers? What is the method to add new people to this team (and/or replace someone resigning)? What we are about to ask seems to be only a minor detail but it's a fundamental change of perspective: we think that Python Maintainer role should be assigned to a team (maybe the pkg-python alioth team can be resurrected) and not to a single person, so with real maintainers in Uploaders. The reasoning is we would like to see a team of peers, not with one developer to take decisions alone. One solution which helped much in other teams was to chose one person, which is not part of the team, as the only one who is allowed to upload the packages and who ensures that fights about changes (they should not happen anyway, but this might keep the heads cool) won't end up with a mess in the upload queue. We suggest to use this only as a last resort solution. Regards, the proposers

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Fri, 21 May 2010 16:39:03 GMT) (full text, mbox, link).

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Fri, 21 May 2010 16:39:03 GMT) (full text, mbox, link).

Message #100 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk> To: Sandro Tosi <morph@debian.org> Cc: 573745@bugs.debian.org, debian-ctte@lists.debian.org Subject: Re: Bug#573745: python maintainance: next steps Date: Fri, 21 May 2010 17:13:35 +0100

Sandro Tosi writes ("Re: Bug#573745: python maintainance: next steps"): > Please also understand that not receiving any update > could give the impression that nothing is being done (that turned out > it's not this case, but still), so a periodic update like "we're still > talking to people, don't worry we're working on it" it's important. Yes, I agree. Sorry, we're not as good at that as we should be. We will try to be better, but also I encourage you to prod us if we seem to have gone quiet. So, thanks for chasing us. > Situations likes this one happened and will happen again (sadly), and the > resolution of this case will be an example case on how such things will > be handled: we have the occasion here to show how Debian acts in > situation where there is some real disagreement in package > maintenance. I absolutely agree. > We can pass the message that no matter how you maintain your packages, > no matter how badly you behave with your peers, [...] I think part of the problem is that many of us are reluctant to get into that kind of "blame game", as it's messy and subjective and unpleasant. But really I think if we have a situation like this one we have to look at the history (and that does take work and it's often not fun reading old flamewars) and yes we do have to make a judgement about what has gone before. That doesn't mean that we have to come out and explicitly point the finger. But we should take these matters into account. > So are you proposing to form the Python core team as an entity > separated from the Python maintainers? Like an entity supervising the > activities of Python maintainer? We are not criticizing the idea, it's > just to understand the proposal. [...] As I understand it the idea currently being proposed is to create a new Python core team, and decree that that team are the new co-maintainers of Python. After that intervention by the TC the core team would be self-governing as with any other package maintenance team - including the ability to hire and fire its own members. Developers who wish to work on Python, but who aren't in the core team, will have to work through the core team just as any developer who isn't a maintainer works on any other package - that may or may not include being given whatever conditional or unconditional upload (or nmu) or commit rights the core team decides. > What we are about to ask seems to be only a minor detail but it's a > fundamental change of perspective: we think that Python Maintainer > role should be assigned to a team (maybe the pkg-python alioth team can > be resurrected) and not to a single person, so with real maintainers in > Uploaders. The reasoning is we would like to see a team of peers, not > with one developer to take decisions alone. Yes. I think we are all agreed on this. The question is who should be on this team. My view is that it should consist of people who have the necessary technical and personal skills, and a history of interest in the Python packages in Debian. It should contain around 4 or 5 people. I don't think anyone should be given a veto over the membership of the core team. So specifically, the fact that we don't believe Matthias will be at all happy, with some possibilities for the core team, does not mean that those possibilities are unacceptable. But we do need to consider every person on their own merits and look at their contributions as a whole and we should pick people who have a history of constructive engagement - this is as much a management role as a technical one. Another difficulty is that it is very difficult to do this kind of appointment without any private discussion. We need to be able to take private input from people who may be reluctant to say "well I know Alice has done a lot of good work but she's a bit of a loose cannon - look at that gnomovision fiasco last year <url>" in public. So can I make a suggestion ? How about we have people send in privately names that you think would make excellent candidates. Email them to any TC member and we can pass it on to the other TC members by private email. > One solution which helped much in other teams was to chose one person, > which is not part of the team, as the only one who is allowed to upload > the packages and who ensures that fights about changes (they should not > happen anyway, but this might keep the heads cool) won't end up with a > mess in the upload queue. We suggest to use this only as a last resort > solution. The team must not include anyone who will play Core Wars in the archive against the other team members. The team should have a good internal working relationship - that doesn't mean never disagreeing, but it does mean dealing constructively with disagreements and honouring the consensus of the team if it goes against you. So this situation should not arise. Ian.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Sat, 22 May 2010 08:57:06 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sat, 22 May 2010 08:57:06 GMT) (full text, mbox, link).

Message #105 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org> To: Sandro Tosi <morph@debian.org> Cc: 573745@bugs.debian.org Subject: Re: Bug#573745: python maintainance: next steps Date: Sat, 22 May 2010 10:53:57 +0200

* Sandro Tosi (morph@debian.org) [100521 16:45]: > Please let us reaffirm our "complains" are also technical: try not put them > aside just dealing with the personal situations around Python. I know. However, we basically have two chances re the technical side: Either we could start micro-managing decisions within debian python (especially as there is more than one topic where there are different opinions), which I don't believe is efficient. Or not. Also, I don't want to end in the finger pointing game - and looking back, I can see mistakes with almost everybody involved (including myself). But it doesn't help to say "this person made more mistakes than that person", because that'd only get very messy. Given all the history and complaints I really believe we need an structural change to get things better. That's why I proposed one. > We > understand there are other reasons that forbid to create a team > including both Matthias and Joss, though. I definitly agree to that sentence. > As already pointed out by Joss in another email, is Matthias being > granted with a veto vote? Can he indefinitely veto people willing to > join such team even if others are OK with them? If that's the case, we > believe this simply won't work and would kill democracy. For the initial setup, I'd like to have only people in the team that are ok by Matthias and are ok by the people who appealed to the tech ctte. If that doesn't work out, we'll have to just decide anyways of course. I think that's fair for an start. For the future replacements, it's up to the group of people how they add new people. > We recently saw Barry Warsaw more involved, which is very positive. We > don't know if you already contacted him, or if he would accept, but he > would be a good candidate, especially one who doesn't have a history in > Debian. I heared good things about Barry at other places as well, so I'd consider him an candidate. > So are you proposing to form the Python core team as an entity > separated from the Python maintainers? Like an entity supervising the > activities of Python maintainer? We are not criticizing the idea, it's > just to understand the proposal. Right (so I'd assume that there will be some overlap soon) - of course, you (the python developers together) can change things as you consider them fit. > If that's the case, what are the > powers of this team over the Python maintainers? Can the core team > force maintainers to implement something or fix a given bug? I'd expect them to have powers the same way like e.g. the release team. Who don't have that much formal power, but anyone involved knows that they're good, knowledgable and you better behave like they want. Obviously also if that team would complain to the tech ctte, it's way easier to accept an complaint. > What is the method to add new people to this > team (and/or replace someone resigning)? "Up to the team to define, but they need to do that pretty soon." > What we are about to ask seems to be only a minor detail but it's a > fundamental change of perspective: we think that Python Maintainer > role should be assigned to a team (maybe the pkg-python alioth team can > be resurrected) and not to a single person, so with real maintainers in > Uploaders. The reasoning is we would like to see a team of peers, not > with one developer to take decisions alone. Can we put it as "there needs to be a team of same-power developers; we don't mind too much how this is expressed in the fields of the package or not"? Andi

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Sat, 29 May 2010 20:51:05 GMT) (full text, mbox, link).

Acknowledgement sent to Vincent Bernat <bernat@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Sat, 29 May 2010 20:51:05 GMT) (full text, mbox, link).

Message #110 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Vincent Bernat <bernat@debian.org> To: 573745@bugs.debian.org, debian-ctte@lists.debian.org Subject: Re: Bug#573745: python maintainance: next steps Date: Sat, 29 May 2010 22:50:17 +0200

OoO En cette matinée pluvieuse du samedi 22 mai 2010, vers 10:53, Andreas Barth <aba@not.so.argh.org> disait : >> As already pointed out by Joss in another email, is Matthias being >> granted with a veto vote? Can he indefinitely veto people willing to >> join such team even if others are OK with them? If that's the case, we >> believe this simply won't work and would kill democracy. > For the initial setup, I'd like to have only people in the team that > are ok by Matthias and are ok by the people who appealed to the > tech ctte. If that doesn't work out, we'll have to just decide anyways > of course. How will this team communicate? Did you consider the fact that Matthias is still currently silent on debian-python@ldo, even when important discussions are run? I don't see any indication that Matthias will become friendly and communicative when the team will be up and running. Most of my interactions ended with a wall of silence [1]. Most interactions are painful [2]. I don't really know how good is Matthias at maintaining packages on the technical side (but I suspect he is very good) but on the social side, he is unable to interact nicely with his users and fellow developers. Does anything indicate that there will be a change here? Will the social side be delegated to the rest of the team? My point is that it is unfair to rule out Josselin which is responsive and communicative in favor of Matthias without having any indication that Matthias' communication skills will improve (which would benefit the other packages that he maintains in the same mood). [1] Some examples: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475440 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486148 [2] Another example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498857 (BTW, there is still a licensing problem in python2.6 binary being linked to OpenSSL and therefore cannot be linked on runtime with any GPL-ed module without OpenSSL exception, including readline; I did not open a bug report about this because of how difficult it is to deal with Matthias) -- I WILL NOT SELL MY KIDNEY ON eBAY I WILL NOT SELL MY KIDNEY ON eBAY I WILL NOT SELL MY KIDNEY ON eBAY -+- Bart Simpson on chalkboard in episode BABF07

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Tue, 15 Jun 2010 07:30:03 GMT) (full text, mbox, link).

Acknowledgement sent to Josselin Mouette <joss@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Tue, 15 Jun 2010 07:30:03 GMT) (full text, mbox, link).

Message #115 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org> To: 573745@bugs.debian.org Subject: Re: Bug#573745: python maintainance: next steps Date: Tue, 15 Jun 2010 09:26:25 +0200

Le samedi 22 mai 2010 à 10:53 +0200, Andreas Barth a écrit : > > As already pointed out by Joss in another email, is Matthias being > > granted with a veto vote? Can he indefinitely veto people willing to > > join such team even if others are OK with them? If that's the case, we > > believe this simply won't work and would kill democracy. > > For the initial setup, I'd like to have only people in the team that > are ok by Matthias and are ok by the people who appealed to the > tech ctte. If that doesn't work out, we'll have to just decide anyways > of course. I’m only speaking for myself here, but I’m not OK with Matthias as part of the core team. > I think that's fair for an start. If you really want to start afresh, you should consider pushing your reasoning to the limit: including only people that are OK by both Matthias and the people who appealed. That list includes neither Matthias nor myself. That would be fair. And that would ensure that people would try to think up new solutions out of the box, instead of re-hashing arguments from the past. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you eat pasta without sauce, it is nothing `- short of communism.” -- Marie

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org> :

Bug#573745 ; Package tech-ctte . (Mon, 28 Jun 2010 22:33:03 GMT) (full text, mbox, link).

Acknowledgement sent to Sandro Tosi <morph@debian.org> :

Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org> . (Mon, 28 Jun 2010 22:33:03 GMT) (full text, mbox, link).

Message #120 received at 573745@bugs.debian.org (full text, mbox, reply):

From: Sandro Tosi <morph@debian.org> To: 573745@bugs.debian.org, debian-ctte@lists.debian.org Subject: Re: Bug#573745: Please decide on Python interpreter packages maintainership Date: Tue, 29 Jun 2010 00:31:28 +0200

Hello, I'm going to reply to some of the more recent emails of this thread: please consider this as a personal reply, not meant to represent the feelings/ideas of other original signers of this appeal. On Wed, May 12, 2010 at 23:28, Andreas Barth <aba@not.so.argh.org> wrote: > * Josselin Mouette (joss@debian.org) [100512 17:27]: >> Le mardi 11 mai 2010 à 23:08 +0200, Andreas Barth a écrit : >> > However, there have been some talks within the tech ctte and with different >> > people inside the Debian python community. That needed time, and we prefer >> > to get to a resolution a bit later than to one that doesn't work. I doubt >> > we can get to a final decision as of now. >> >> First of all I’d like to express my sadness to see these discussions, >> again, having being conducted privately. We have now several years >> behind us that show this is a bad idea, and the CTTE, asked to resolve >> this matter, chose to adopt the same technique. > > So you think the only acceptable option is to take away the > maintainership from Matthias? And even if we would do that, how can we > be sure that this resolves all the issues we have? Let's turn this way: we already know what it's like with him maintaining python, and I'm quite sure it won't be worst, so at least we have the occasion to see how a really community maintained (in the sense of people coming from the python community) would work, and I bet it will work well. >> > I don't want to loose Matthias contributions to python >> > within Debian and the python community. >> >> This is completely irrelevant, unless Matthias threatened to stop >> contributing unless he can keep setting the rules. But I know the CTTE >> wouldn’t take such “don’t touch my garden” blackmail into account, of >> course. > > I would expect that deciding to remove him from being maintainer would > demotivate him - at least that would be a natural thing to happen. I can understand that, but are we only talking about python packages or all the other packages Matthias maintains? I think Matthias has concentrated in his hands a lot of powers, by maintaining key packages (bash, binutils, gcc, java, python, and several others), thus if the fear of removing him from python maintainership is related to the fear of some of our most important packages will be under-maintained (even if they *already* need a lot more love than now) or even worst, sabotaged, I think we have a much bigger problem than simply deciding who's to maintain python. If we are threaten by the feelings of a single person for our core packages, then I consider we're making a mistake and Debian is loosing the control over itself, because of too much power in one pair of hands, and we should fix this really soon. I just hope to be over-pessimistic, but I also want to express one of my fears about the "not remove Matthias from python maintainers" proposal. On Thu, May 13, 2010 at 11:15, Andreas Barth <aba@not.so.argh.org> wrote: > * Josselin Mouette (joss@debian.org) [100513 03:09]: >> Le mercredi 12 mai 2010 à 23:28 +0200, Andreas Barth a écrit : >> > > > I don't want to loose Matthias contributions to python >> > > > within Debian and the python community. >> > > >> > > This is completely irrelevant, unless Matthias threatened to stop >> > > contributing unless he can keep setting the rules. But I know the CTTE >> > > wouldn’t take such “don’t touch my garden” blackmail into account, of >> > > course. >> > >> > I would expect that deciding to remove him from being maintainer would >> > demotivate him - at least that would be a natural thing to happen. >> >> This line of reasoning is fallacious. I could reverse it and talk about >> people who are demotivated because they feel the current maintainer is >> incompetent. How could this help guiding the decision? > > Don't you see that we want to end that? absolutely, thanks for the work you all do "behind the scene", and I believe we are working towards this goal. I still think, tho, that in strong situations, strong decisions have to be taken, else the solution we reach will only work for some time, and then we'll fall back to where we are now. >> > > It means giving a veto power to Matthias about who can or cannot >> > > contribute, while not giving this power to others. >> > >> > Eh, where does that proposal give Matthias veto power? >> >> If Matthias can refuse someone to be part of the core team because he >> doesn’t trust that person, that’s a veto power. > > For the initial setup, I would like to have people in the core team > that are ok by both Matthias and the people who brought this to the > tech ctte (e.g. you). If that doesn't work out, we'll of course decide > who is in the core team. I think that's reasonable. Sadly, I think that the intersection of the two sets of "people Matthias is ok with" and "people ok with the signer of this appeal" is quite empty :) That's because I see Matthias as a single player, and "forcing" him to work in a team will end up in: 1. him doing nothing 2. him keeps doing as of now, with more frustration for the others in that team. Also, an additional level of "management" has to be well received from who has to be managed: are we really sure Matthias will follow even controversial decisions (so in opposition to some of his ideas) the core team will take? On Thu, May 13, 2010 at 15:21, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote: > Andreas Barth writes ("Re: Bug#573745: python maintainance: next steps"): >> For the initial setup, I would like to have people in the core team >> that are ok by both Matthias and the people who brought this to the >> tech ctte (e.g. you). If that doesn't work out, we'll of course decide >> who is in the core team. I think that's reasonable. > > We should not forget the effect our approach here will have on other > maintainers. If we act now to give the existing maintainer a veto, to > spare their feelings and avoid demotivating them, if perhaps it was > they who were in a large part the reason for the bad situation, then > we are saying to every maintainer that they do not need to worry: if > they are at the centre of a storm of this kind, we will still honour > their ownership of the package. > > Perhaps what you are forgetting is that the maintainer has a > responsibility not just for the technical contents of the package, but > also to facilitate other people's work as it relates to their package. > The maintainer has a pretty much unfettered ability to delegate, to > create a team of their choice, and so on; that comes with the > responsibility to do so when appropriate. So one thing we need to > consider is whether in this case the maintainer has failed in that > task. > > Or to put it another way, if the maintainer wanted help from a team > acceptable to them, they could have simply decreed it. > > I think we do need to consider whether it would be best if the > maintainer put their evident technical skills to use elsewhere. Not > just in the context of one package, but also to so that the project > can see that if you really can't manage to work with people, and act > as a blocker, you may be deposed. Full and complete ack. Thanks for saying it, i couldn't be more direct and precise. I subscribe all you said above. On Sun, May 16, 2010 at 18:09, Luk Claes <luk@debian.org> wrote: > On 05/13/2010 03:21 PM, Ian Jackson wrote: >> Andreas Barth writes ("Re: Bug#573745: python maintainance: next steps"): >> Perhaps what you are forgetting is that the maintainer has a >> responsibility not just for the technical contents of the package, but >> also to facilitate other people's work as it relates to their package. >> The maintainer has a pretty much unfettered ability to delegate, to >> create a team of their choice, and so on; that comes with the >> responsibility to do so when appropriate. So one thing we need to >> consider is whether in this case the maintainer has failed in that >> task. > > The question is indeed if the maintainer failed to properly maintain the > package in the given circumstances. Note that the circumstances are by far > trivial and that the maintainer showed only good intentions AFAICS. Note this is at least debatable; I don't want to reiterate all the points about python 2.6, just a couple: 14 months between upstream release of 2.6 and the upload in sid without a good reason (maybe some secret ones?) and a complete disinterest in the 2.6 transition. IMO this is not "only good intentions". > also that the maintainer already welcomed some people to co-maintain, but after a long long process of convincing him (and circumstances that can be a little suspect); I won't call it "welcoming someone". > hold strongly to some pre-conditions as he wants to avoid the real mess that > resulted from the python 2.6 transition in Ubuntu. ehm... the python 2.6 transition is the main blocker preventing from freezing squeeze, so it ends up to be a huge a mess: these pre-conditions didn't work, another big signal things must change. On contrary of Ubuntu (that set 2.6 as default in 9.04, and since then many packages were left broken, sigh), Debian managed to have skilled people working on the transition, identifying packages with bugs, filing them, NMU them and sponsor them when needed. Matthias did nothing of these activity. You can call it "fingerpointing", but they are facts: he doesn't participate in the transition, he wanted to handle things his own way, and he want other people to "obey his will", without complaining, and doing the actual work. Sorry, I won't stand silent to this situation. >> Or to put it another way, if the maintainer wanted help from a team >> acceptable to them, they could have simply decreed it. > > That's true for the package maintenance, that is very well untrue for the > circumstances and the policy changes he wants to have implemented to avoid > similar trouble with the link farm as the ones that happened in Ubuntu. this reduce to Debian being his playground for his Ubuntu activities? Having the same maintainers between Debian and Ubuntu might be a nice thing to have, but strongly not if the price to pay is to have Debian always late then Ubuntu, or "half-baked" or the sandbox for policy changes really aimed for Ubuntu, or anything else where Debian is not leading the change. >> I think we do need to consider whether it would be best if the >> maintainer put their evident technical skills to use elsewhere. Not >> just in the context of one package, but also to so that the project >> can see that if you really can't manage to work with people, and act >> as a blocker, you may be deposed. > > That would rule out any of the vocal opposants as the new (co-)maintainers > IMHO as they are as much part of shapening a blocker as the current > maintainer AFAICS. It's awkward to accuse u