Bug#573745: python maintainance: next steps
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
Reply to: