[Python-Dev] Release 2.0.1: Heads Up

[Moshe Zadka]

Greetings, earthlings!

As Guido said in the last conference, there is going to be a bugfix release
of Python 2.0, Python 2.0.1. Originally meant to be only a license bugfix
release, comments in the Python community have indicated a need for a real
bugfix release. PEP 6[1] has been written by Aahz, which outlines a procedure
for such releases. With Guido's blessing, I have volunteered to be the
Patch Czar (see the PEP!) for the 2.0.1 release. In this job, I intend
to be feared and hated throughout the Python community -- men will 
tremble to hear the sounds of my footsteps...err...sorry, got sidetracked.

This is the first Python pure bugfix release, and I feel a lot of weight
rests on my shoulders as to whether this experiment is successful. Since
this is the first bugfix release, I intend to be ultra-super-conservative.
I can live with a release that does not fix all the bug, I am very afraid
of a release that breaks a single person's code. Such a thing will give
Python bugfix releases a very bad reputation. So, I am going to be a very
strict Czar.

I will try to follow consistent rules about which patches to integrate,
but I am only human. I will make all my decisions in the public, so they
will be up for review of the community.

There are a few rules I intend to go by

1. No fixes which you have to change your code to enjoy. (E.g., adding a new
   function because the previous API was idiotic)
2. No fixes which have not been applied to the main branch, unless they
   are not relevant to the main branch at all. I much prefer to get a pointer
   to an applied patch or cvs checkin message then a fresh patch. Of course,
   there are cases where this is impossible, so this isn't strict.
3. No fixes which have "stricter checking". Stricter checking is a good
   thing, but not in bug fix releases.
4. No fixes which have a reasonable chance to break someone's code. That
   means that if there's a bug people have a good change of counting on,
   it won't be fix.
5. No "improved documentation/error message" patches. This is stuff that
   gets in people's eyeballs -- I want bugfix upgrade to be as smooth
   as possible.
6. No "internal code was cleaned up". That's a good thing in the development
   branch, but not in bug fix releases.

Note that these rules will *not* be made more lenient, but they might
get stricter, if it seems such strictness is needed in order to make
sure bug fix releases are smooth enough.

However, please remember that this is intended to help you -- the Python
using community. So please, let me know of bugfixes that you need or want
in Python 2.0. I promise that I will consider every request.
Note also, that the Patch Czar is given very few responsibilities ---
all my decisions are subject to Guido's approval. That means that he
gets the final word about each patch.

I intend to post a list of patches I intend to integrate soon -- at the
latest, this Friday, hopefully sooner. I expect to have 2.0.1a1 a week
after that, and further schedule requirements will follow from the
quality of that release. Because it has the dual purpose of also being
a license bugfix release, schedule might be influenced by non-technical
issues. As always, Guido will be the final arbitrator.

-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez@debian.org  |http://www.{python,debian,gnu}.org