Bug#573745: Please decide on Python interpreter packages maintainership
* 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
Reply to: