[Python-Dev] Goals for patch selection for 2.1.2 (original) (raw)

Anthony Baxter anthony@interlink.com.au
Fri, 19 Oct 2001 14:31:37 +1000

Hi there,

I'm happy enough to be the release manager for 2.1.2 - I've a reasonably high amount of CVS experience, so that shouldn't be a problem.

Here's my current thoughts for selecting patches for a 2.1.2 release. Feedback would be appreciated. I plan to post this to python-list and ask people for suggestions for "must have" fixes. This could possibly be added to PEP 006 once it's nailed down.

Code that adds new packages new modules new methods is out. (duh)

Anything that introduces a large chunk of code should be out.

Anyone who's subclassing a standard library class shouldn't get screwed over - even if they're playing with the internals of the classes.

C code changes should be very very conservative. Bug fixes that fix problems that people are having are good - anything else should be regarded with a hell of a lot of suspicion. And the "don't introduce large chunks of new code" test would obviously apply here.

Things that shouldn't be considered: Fixes that "make something work better" Fixes that "remove a nasty workaround"

In general, I'd like the starting point for any patch to be considered as "guilty until proven necessary".

An example (from a discussion with Guido) is the recent profiler fixup:

We made two sets of changes to the profiler. One fixed profile.py to properly interpret exception events. This one should go in (I specifically tested it with Python 1.5.2 and 2.1).

The other changed the C code that generates profiling events to suppress exception events, and to generate return events even when a frame is exited with an exception. That one should not go in. Thanks, Anthony

Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.