Goals for patch selection for 2.1.2
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.
Thanks, Anthony! It's good to see someone volunteering without too much pressure. What's your SF id, so we can give you checkin permission? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum writes:
Thanks, Anthony! It's good to see someone volunteering without too much pressure. What's your SF id, so we can give you checkin permission?
"anthonybaxter". I've added him and set up permissions. Anthony, if I've left out any permissions, speak up and we'll get them fixed. Thanks for helping out! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
Fred, could you update PEP 6 to make Anthony the 2.1.2 manager, or should I submit a patch to you? (Yeah, yeah, one of these days I'll actually do enough work to make it worth SF privileges.) Anthony Baxter wrote:
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.
I have zero objection to any single release using stricter guidelines than PEP 6 requires, but PEP 6 started life as a set of guidelines for both "bugfix" and "patch" releases. While I don't have a lot of objection to tightening up PEP 6 a bit more to reflect the fact that it focuses entirely on bugfix releases now, there are enough gray areas about what is a bug vs. feature that I don't want to make the PEP quite as strict as you plan to for 2.1.2. I don't want to get into a long discussion about this on python-dev; I'll respond to your post on c.l.py. I just wanted to make a short statement of principle in case anyone wants to get involved later. -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista We must not let the evil of a few trample the freedoms of the many.
"AB" == Anthony Baxter <anthony@interlink.com.au> writes:
AB> Things that shouldn't be considered: [...] AB> Fixes that "remove a nasty workaround" AB> In general, I'd like the starting point for any patch to be AB> considered as "guilty until proven necessary". Do you have an opinion on the recent change to traceback.c (make it collectable)? I think it's a good candidate for 2.1.2 even though it doesn't meet the criteria above :-). It removes the nasty workaround that you *never* exit a function with a local variable that points to a traceback that references the function. There's a bit of C code (most of it probably extending the type structure for tracebacks), but it's simple stuff, thoroughly tested by the current test suite, and it's a *nasty* problem in practice. Two other things I thought of on this thread: We got out of the habit of marking changes in 2.2 as potential bug fixes, because we didn't expect to have a 2.1.2 release. I think we should continue marking checkins this way indefinitely. We may not have a 2.1.3 and a 2.2.2, but it's pretty easy to mark the checkin just in case we do make such a release. I'd like to update the compiler package in Tools/compiler, because I've fixed a number of nasty bugs, e.g. computing a stack size that is too small for a function. But I don't know if I'll have time. Once you've got a schedule, I'll let you know if I can manage it. Jeremy
AB> In general, I'd like the starting point for any patch to be AB> considered as "guilty until proven necessary".
Do you have an opinion on the recent change to traceback.c (make it collectable)? I think it's a good candidate for 2.1.2 even though it doesn't meet the criteria above :-).
Hm. In 2.2, the C API for the garbage collector is different from 2.1, so backporting this would require extra work. Also, you'd probably have to add GC to frames as well to reap the benefits. To me this particular problem feels like a bug that's almost a feature (everybody knows about it, it's documented, etc.), and I think we'd be better off not fixing this in 2.1.2. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Jeremy]
Do you have an opinion on the recent change to traceback.c (make it collectable)? I think it's a good candidate for 2.1.2 even though it doesn't meet the criteria above :-).
Guido's right: that change alone won't do any good. Frame objects need to be chased by gc too, else the cycle would survive. However, adding frame objects to gc caused a measurable slowdown, which I judged tolerable in 2.2 because 2.2 got enough non-bugfix speedup work to cancel it out (at the time -- I expect we're losing again by now). if-it-ain't-a-pure-self-contained-bugfix-it's-dubious-at-best-ly y'rs - tim
participants (6)
-
aahz＠rahul.net -
Anthony Baxter -
Fred L. Drake, Jr. -
Guido van Rossum -
Jeremy Hylton -
Tim Peters