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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
