[Python-Dev] Goals for patch selection for 2.1.2

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.