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