I had previously wanted to release Python 2.6.3 over the summer, but for various personal reasons, the summer was just too insane. I'd like to reschedule a 2.6.3 release, shooting for final release on 25- September.
We should probably do a release candidate, so I'd like to make that on 23-September.
Does anybody have objections to that schedule? If not, I'll try to spend some time over the next few days looking at outstanding bugs, and marking release blockers, etc.
-Barry
Barry Warsaw wrote:
I had previously wanted to release Python 2.6.3 over the summer, but for various personal reasons, the summer was just too insane. I'd like to reschedule a 2.6.3 release, shooting for final release on 25-September.
We should probably do a release candidate, so I'd like to make that on 23-September.
Does anybody have objections to that schedule? If not, I'll try to spend some time over the next few days looking at outstanding bugs, and marking release blockers, etc.
2 days seems a little short (particularly allowing 24 hours or so for the Windows and Mac installers to be produced). Haven't we historically left a week between the RC and actual release for maintenance releases?
Cheers, Nick.
On Sep 9, 2009, at 9:29 AM, Nick Coghlan wrote:
Barry Warsaw wrote:
I had previously wanted to release Python 2.6.3 over the summer, but for various personal reasons, the summer was just too insane. I'd like to reschedule a 2.6.3 release, shooting for final release on 25- September.
We should probably do a release candidate, so I'd like to make that on 23-September.
Does anybody have objections to that schedule? If not, I'll try to spend some time over the next few days looking at outstanding bugs, and marking release blockers, etc.
2 days seems a little short (particularly allowing 24 hours or so for the Windows and Mac installers to be produced). Haven't we historically left a week between the RC and actual release for maintenance releases?
Actually, I've rarely done rc's for point releases. JFDI :)
I still want to release by the 25th, but I'd be willing to move the rc to Monday the 21st. We're really just trying to avoid a brown bag moment, so that should give us enough time to double check the releases.
-Barry
In article 11A6545D-7204-4F61-B55B-1CC77CB5645E@python.org, Barry Warsaw barry@python.org wrote:
I still want to release by the 25th, but I'd be willing to move the rc to Monday the 21st. We're really just trying to avoid a brown bag moment, so that should give us enough time to double check the releases.
The recent release of OS X 10.6 (Snow Leopard) has triggered a fair amount of 2.6 bug tracker activity, since 10.6 now includes 2.6 (2.6.1) and a 64-bit version at that. A number of patches have either just been checked-in over the past couple of weeks or are getting some exposure before check-in. Given the timing and the (appropriate) infrequency of 2.6.x releases, I think it would be unfortunate to push 2.6.3 out the door without ensuring that it works well on 10.6. Therefore, I propose that 2.6.3 should have 10.6 compatibility as a "release goal".
Without trying to put Ronald on the spot (too much!), it would be a good idea to get his assessment where things stand wrt 2.6 on 10.6 before setting a final release date.
On 9 Sep, 2009, at 19:29, Ned Deily wrote:
Without trying to put Ronald on the spot (too much!), it would be a good idea to get his assessment where things stand wrt 2.6 on 10.6 before setting a final release date.
MacOS X 10.6 support should be stable now, except for a critical issue with IDLE: opening a new window hangs IDLE (issue 6864).
That said, I haven't scanned the issue tracker for more 10.6 related issues.
BTW. I'm fine with a sept. 25th release, that should give us enough time to shake out issues with OSX 10.6 support.
Ronald
On Sep 9, 2009, at 2:19 PM, Ronald Oussoren wrote:
MacOS X 10.6 support should be stable now, except for a critical issue with IDLE: opening a new window hangs IDLE (issue 6864).
That said, I haven't scanned the issue tracker for more 10.6 related issues.
I just opened issue 6877 and provided a patch that I use for a long time already. It would be nice to have it in the release though since other people could benefit from it too.
It resolves a BusError crash when Python readline module is built with a native Mac OS X editline (emulates readline). The patch fixes the issue and enables use of readline module on Mac OS X.
Best regards,
Zvezdan
In article C11F8211-8938-4C68-8221-C3C73E8E517B@mac.com, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 9 Sep, 2009, at 19:29, Ned Deily wrote:
Without trying to put Ronald on the spot (too much!), it would be a good idea to get his assessment where things stand wrt 2.6 on 10.6 before setting a final release date.
MacOS X 10.6 support should be stable now, except for a critical issue with IDLE: opening a new window hangs IDLE (issue 6864).
That said, I haven't scanned the issue tracker for more 10.6 related issues.
BTW. I'm fine with a sept. 25th release, that should give us enough time to shake out issues with OSX 10.6 support.
Ronald---------------------------------------------------------------------
Some or all earlier Mac binaries of Python 2.6 were not compatible with 3rd party Aqua Tcl/Tk (e.g. ActiveState's versions) -- at least on MacOS X 10.5. I hope that will be fixed with the current release.
-- Russell
On Sep 9, 2009, at 1:29 PM, Ned Deily wrote:
In article 11A6545D-7204-4F61-B55B-1CC77CB5645E@python.org, Barry Warsaw barry@python.org wrote:
I still want to release by the 25th, but I'd be willing to move the rc to Monday the 21st. We're really just trying to avoid a brown bag moment, so that should give us enough time to double check the releases.
The recent release of OS X 10.6 (Snow Leopard) has triggered a fair amount of 2.6 bug tracker activity, since 10.6 now includes 2.6 (2.6.1) and a 64-bit version at that. A number of patches have either just been checked-in over the past couple of weeks or are getting some exposure before check-in. Given the timing and the (appropriate) infrequency of 2.6.x releases, I think it would be unfortunate to push 2.6.3 out the door without ensuring that it works well on 10.6. Therefore, I propose that 2.6.3 should have 10.6 compatibility as a "release goal".
Without trying to put Ronald on the spot (too much!), it would be a good idea to get his assessment where things stand wrt 2.6 on 10.6 before setting a final release date.
I'm hoping that Python won't have any issues building and running on 10.6, but I don't have it yet so I can't personally test it out.
How would you quantify "works well"? Do you have any thoughts on tests you'd run other than the standard test suite? If 2.6.3 is shown to pass its test suite on 10.5.x, is that good enough? Are the specific bug fixes necessary for 10.6?
-Barry
In article 9D506035-7C2D-4929-A134-E88EEB7B7D9E@python.org, Barry Warsaw barry@python.org wrote:
On Sep 9, 2009, at 1:29 PM, Ned Deily wrote:
In article 11A6545D-7204-4F61-B55B-1CC77CB5645E@python.org, Barry Warsaw barry@python.org wrote:
I still want to release by the 25th, but I'd be willing to move the rc to Monday the 21st. We're really just trying to avoid a brown bag moment, so that should give us enough time to double check the releases.
The recent release of OS X 10.6 (Snow Leopard) has triggered a fair amount of 2.6 bug tracker activity, since 10.6 now includes 2.6 (2.6.1) and a 64-bit version at that. A number of patches have either just been checked-in over the past couple of weeks or are getting some exposure before check-in. Given the timing and the (appropriate) infrequency of 2.6.x releases, I think it would be unfortunate to push 2.6.3 out the door without ensuring that it works well on 10.6. Therefore, I propose that 2.6.3 should have 10.6 compatibility as a "release goal".
Without trying to put Ronald on the spot (too much!), it would be a good idea to get his assessment where things stand wrt 2.6 on 10.6 before setting a final release date.
I'm hoping that Python won't have any issues building and running on 10.6, but I don't have it yet so I can't personally test it out.
How would you quantify "works well"? Do you have any thoughts on tests you'd run other than the standard test suite? If 2.6.3 is shown to pass its test suite on 10.5.x, is that good enough? Are the specific bug fixes necessary for 10.6?
Running the standard test suite on 10.6 and seeing no regressions compared to the same suite on 10.5.x seems a reasonable necessary requirement. We have the resources to do that. Beyond that, as Ronald suggests, I think it important to go through the open issues in the next couple of days and identify and flag any potential release-blockers (besides the IDLE problem already mentioned).
One other open issue is 64-bit support in the python.org OS X installer. There have been discussions and requests in the past and, with Apple providing 64-bit out of the box in 10.6, it seems like it's time to provide something on python.org as well. One option: continue to provide a 32-bit only installer for ppc and i386 for 10.3.9 and beyond and add a second installer image with 3-way (ppc, i386, x86_64 but no ppc64) 32/64 for 10.5 and beyond. Ronald, is that your current thinking?
On 10 Sep, 2009, at 18:23, Ned Deily wrote:
In article 9D506035-7C2D-4929-A134-E88EEB7B7D9E@python.org, Barry Warsaw barry@python.org wrote:
On Sep 9, 2009, at 1:29 PM, Ned Deily wrote:
In article 11A6545D-7204-4F61-B55B-1CC77CB5645E@python.org, Barry Warsaw barry@python.org wrote:
I still want to release by the 25th, but I'd be willing to move the rc to Monday the 21st. We're really just trying to avoid a brown bag moment, so that should give us enough time to double check the releases.
The recent release of OS X 10.6 (Snow Leopard) has triggered a fair amount of 2.6 bug tracker activity, since 10.6 now includes 2.6 (2.6.1) and a 64-bit version at that. A number of patches have either just been checked-in over the past couple of weeks or are getting some exposure before check-in. Given the timing and the (appropriate) infrequency of 2.6.x releases, I think it would be unfortunate to push 2.6.3 out the door without ensuring that it works well on 10.6. Therefore, I propose that 2.6.3 should have 10.6 compatibility as a "release goal".
Without trying to put Ronald on the spot (too much!), it would be a good idea to get his assessment where things stand wrt 2.6 on 10.6 before setting a final release date.
I'm hoping that Python won't have any issues building and running on 10.6, but I don't have it yet so I can't personally test it out.
How would you quantify "works well"? Do you have any thoughts on tests you'd run other than the standard test suite? If 2.6.3 is shown to pass its test suite on 10.5.x, is that good enough? Are the specific bug fixes necessary for 10.6?
Running the standard test suite on 10.6 and seeing no regressions compared to the same suite on 10.5.x seems a reasonable necessary requirement. We have the resources to do that. Beyond that, as Ronald suggests, I think it important to go through the open issues in the next couple of days and identify and flag any potential release-blockers (besides the IDLE problem already mentioned).
The IDLE issue is IMHO a release blocker, as is issue 6851.
One other open issue is 64-bit support in the python.org OS X installer. There have been discussions and requests in the past and, with Apple providing 64-bit out of the box in 10.6, it seems like it's time to provide something on python.org as well. One option: continue to provide a 32-bit only installer for ppc and i386 for 10.3.9 and beyond and add a second installer image with 3-way (ppc, i386, x86_64 but no ppc64) 32/64 for 10.5 and beyond. Ronald, is that your current thinking?
64-bit support can wait until after 2.6.3 is released. I need time to work out what's needed go create a good installer (and not just running the current build-installer.py script because that includes to much for a binary that doesn't run on 10.3.9). That won't happen before 2.6.3 is released because I'm too thinly stretched even without working on that.
Ronald
On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote:
The IDLE issue is IMHO a release blocker, as is issue 6851.
So that leaves 4 release blockers for 2.6.3. Three of these are assigned to Ronald. Ronald are you sure you will have time to fix these by then? The one I'm still uncertain on is the IDLE hang. If this only affects OS X 10.6 and there is no progress on it by the time 2.6.3 is otherwise ready, I'm willing to knock this down in severity.
Martin, you have the other showstopper bug for 2.6.3. Do you think you will be able to fix that one in time?
-Barry
On Wed, Sep 16, 2009 at 05:52, Barry Warsaw barry@python.org wrote:
On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote:
The IDLE issue is IMHO a release blocker, as is issue 6851.
So that leaves 4 release blockers for 2.6.3. Three of these are assigned to Ronald. Ronald are you sure you will have time to fix these by then? The one I'm still uncertain on is the IDLE hang. If this only affects OS X 10.6 and there is no progress on it by the time 2.6.3 is otherwise ready, I'm willing to knock this down in severity.
Martin, you have the other showstopper bug for 2.6.3. Do you think you will be able to fix that one in time?
That issue doesn't require Martin specifically. I just needed to know if changing the BaseException struct would be bad (Georg answered w/ "yes"). It will probably fall on to me (or Georg if his proposed solution pans out) to get this fixed.
-Brett
On 16 Sep, 2009, at 14:52, Barry Warsaw wrote:
On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote:
The IDLE issue is IMHO a release blocker, as is issue 6851.
So that leaves 4 release blockers for 2.6.3. Three of these are assigned to Ronald. Ronald are you sure you will have time to fix these by then? The one I'm still uncertain on is the IDLE hang. If this only affects OS X 10.6 and there is no progress on it by the time 2.6.3 is otherwise ready, I'm willing to knock this down in severity.
I don't know for sure if I'll be able to fix these issues, I'll basicly just have time to work on this during the weekend.
* IDLE hang on OSX 10.6: I don't really know where to start looking, this may have something to do with Tk-Cocoa (which is used on 10.6 and not on earlier releases). There is a patch for Tk-Cocoa support on the tracker, but I haven't had time yet to fully test that.
* Compile error for ctypes on 10.6: Should be easy to fix. Apple has released the sources of the copy of libffi included with 10.6.1, I'll use that to work on a patch.
* Crash with urllib and threads on OSX 10.6: This probably requires rewriting some code using ctypes in C. The crash seems to occur when CoreFoundation tries to initialise itself after being loaded on a secondairy thread by ctypes. To make matters worse the ctypes type annotations in urllib are not correct for 64-bit code (but the crash happens in 32-bit mode as well)
Ronald
Barry Warsaw wrote:
On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote:
The IDLE issue is IMHO a release blocker, as is issue 6851.
So that leaves 4 release blockers for 2.6.3.
What about this bug: http://bugs.python.org/issue3890 It appears to me that the SSL module is broken in the 2.6.x line on all platforms in one of its most common uses (non-blocking). It also seems that the problem and solution are well understood, so the solution would make a good candidate for 2.6.3? Tom.
qwavel tmm@fastmail.fm wrote:
What about this bug: http://bugs.python.org/issue3890 It appears to me that the SSL module is broken in the 2.6.x line on all platforms in one of its most common uses (non-blocking). It also seems that the problem and solution are well understood, so the solution would make a good candidate for 2.6.3? Tom.
I might quibble about "most common uses", but I agree this would be a good idea.
Bill
On Sep 19, 2009, at 2:51 PM, qwavel wrote:
What about this bug: http://bugs.python.org/issue3890 It appears to me that the SSL module is broken in the 2.6.x line on all platforms in one of its most common uses (non-blocking). It also seems that the problem and solution are well understood, so the solution would make a good candidate for 2.6.3?
I made this a release blocker, but reserve the right to bump it down again.
-Barry
On Fri, Sep 25, 2009 at 3:14 PM, Barry Warsaw barry@python.org wrote:
On Sep 19, 2009, at 2:51 PM, qwavel wrote:
What about this bug: http://bugs.python.org/issue3890 It appears to me that the SSL module is broken in the 2.6.x line on all platforms in one of its most common uses (non-blocking). It also seems that the problem and solution are well understood, so the solution would make a good candidate for 2.6.3?
I made this a release blocker, but reserve the right to bump it down again.
-Barry
Barry - this is your call, but I think http://bugs.python.org/issue6990 should be a rel blocker too.
jesse
On Sep 25, 2009, at 4:18 PM, Jesse Noller wrote:
Barry - this is your call, but I think http://bugs.python.org/issue6990 should be a rel blocker too.
Done. -Barry
In article 9D506035-7C2D-4929-A134-E88EEB7B7D9E@python.org, Barry Warsaw barry@python.org wrote:
On Sep 9, 2009, at 1:29 PM, Ned Deily wrote:
The recent release of OS X 10.6 (Snow Leopard) has triggered a fair amount of 2.6 bug tracker activity, since 10.6 now includes 2.6 (2.6.1) and a 64-bit version at that. A number of patches have either just been checked-in over the past couple of weeks or are getting some exposure before check-in. Given the timing and the (appropriate) infrequency of 2.6.x releases, I think it would be unfortunate to push 2.6.3 out the door without ensuring that it works well on 10.6. Therefore, I propose that 2.6.3 should have 10.6 compatibility as a "release goal". Without trying to put Ronald on the spot (too much!), it would be a good idea to get his assessment where things stand wrt 2.6 on 10.6 before setting a final release date.
I'm hoping that Python won't have any issues building and running on 10.6, but I don't have it yet so I can't personally test it out.
How would you quantify "works well"? Do you have any thoughts on tests you'd run other than the standard test suite? If 2.6.3 is shown to pass its test suite on 10.5.x, is that good enough? Are the specific bug fixes necessary for 10.6?
To follow-up, I've now run the usual "standard" OS X installer builds and regression tests using 2.6.3rc1 plus a few additional tests (IDLE and package installation) and have found no regressions from 2.6.2 and verified that some release-blocker problems have indeed been fixed. In particular, Issue6957 regarding extensions module building on OS X 10.6 is fixed as discussed in the issue.
The tests involved the target python.org installer configuration:
- deployment target = 10.3, 2-way i386/ppc, Tk 10.4, built on 10.5 -> regrtest on 10.4 ppc, 10.5 ppc, 10.6 i386
plus the following additional configurations:
- deployment target = 10.3, 2-way i386/ppc, Tk 10.4, built on 10.4: -> regrtest on 10.4 ppc, 10.5 ppc, 10.6 i386
- deployment target = 10.5, 4-way i386/x86_64/ppc/ppc64, Tk 10.4, built on 10.5: -> regrtest on 10.5 ppc, 10.6 i386, 10.6 x86_64
plus, a quick check of the currently unsupported configuration, with no new regressions noted:
- deployment target = 10.6, 2-way i386/x86_64, Tk 10.5, built on 10.6: -> regrtest on 10.6 x86_64
As noted in various tracker issues, there are still a few unresolved issues with universal builds built on 10.6 (e.g. 32-bit vs 64-bit selection, IDLE with Tk 8.5) which is why this last installer build configuration is currently unsupported.
In my opinion, the standard python.org OS X installer for 2.6.3 now "works well" on 10.4, 10.5, and 10.6 and is ready for release.
On Sep 30, 2009, at 12:29 AM, Ned Deily wrote:
In my opinion, the standard python.org OS X installer for 2.6.3 now "works well" on 10.4, 10.5, and 10.6 and is ready for release.
Fantastic, thanks. Martin's uploaded the Windows binaries so I'll make the announcement now. No commits to the 2.6 tree are allowed without checking with me first (via IRC, bug tracker or email). I'll make an exception for svnmerge bookkeeping.
-Barry
2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86, Windows 32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did.
-srid
On Wed, 30 Sep 2009 05:34:02 -0700, Barry Warsaw barry@python.org wrote:
On Sep 30, 2009, at 12:29 AM, Ned Deily wrote:
In my opinion, the standard python.org OS X installer for 2.6.3 now "works well" on 10.4, 10.5, and 10.6 and is ready for release.
Fantastic, thanks. Martin's uploaded the Windows binaries so I'll make the announcement now. No commits to the 2.6 tree are allowed without checking with me first (via IRC, bug tracker or email). I'll make an exception for svnmerge bookkeeping.
-Barry
On Wed, 30 Sep 2009 12:44:14 -0700, Barry Warsaw barry@python.org wrote:
2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86, Windows 32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did. Thanks for the feedback! Did you run the test suite on any of these?
I will run the tests sometime tonight and let you know.
-srid
On Wed, 30 Sep 2009 13:06:47 -0700, Sridhar Ratnakumar sridharr@activestate.com wrote:
On Wed, 30 Sep 2009 12:44:14 -0700, Barry Warsaw barry@python.org wrote:
2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86, Windows 32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did. Thanks for the feedback! Did you run the test suite on any of these?
I will run the tests sometime tonight and let you know.
No new significant failures have been found. (Some trivial issues have been reported in the bug tracker).
-srid
Barry Warsaw schrieb:
I had previously wanted to release Python 2.6.3 over the summer, but for various personal reasons, the summer was just too insane. I'd like to reschedule a 2.6.3 release, shooting for final release on 25-September.
I'm travelling that week (as well as the time until then), so I would prefer to make it a week later.
Regards, Martin
On Sep 10, 2009, at 12:57 PM, Martin v. Löwis wrote:
Barry Warsaw schrieb:
I had previously wanted to release Python 2.6.3 over the summer, but for various personal reasons, the summer was just too insane. I'd like to reschedule a 2.6.3 release, shooting for final release on 25- September.
I'm travelling that week (as well as the time until then), so I would prefer to make it a week later.
Cool, thanks Martin. Let's make it:
2.6.3rc1 on 29-sep 2.6.3 final on 02-oct
That gives us an extra day between rc and final.
-Barry
Barry Warsaw wrote:
If not, I'll try to spend some time over the next few days looking at outstanding bugs, and marking release blockers, etc.
I'd like to draw attention to:
http://bugs.python.org/issue5949
Which is a regression of imaplib.py introduced in r57680.
Ever since I switched to python 2.6 on my box, I have had issues with getmail[1] getting stuck in an infinite loop swallowing memory (note: only applies to IMAP SSL connections). While this code is present in older versions of python, it seems to have become a problem recently (2009-05-06 is the earliest report on the issue) perhaps due to a version bump of OpenSSL? I never noticed the problem in python2.5 even though the code is unchanged. Nevertheless, the code is clearly wrong and should be corrected.
I would appreciate this bug being resolved before the next release as it effects me on a daily basis. I have submitted a patch, which reflects my local solution.
-Scott
[1] http://pyropus.ca/software/getmail/
Scott Dial wrote:
While this code is present in older versions of python, it seems to have become a problem recently (2009-05-06 is the earliest report on the issue) perhaps due to a version bump of OpenSSL? I never noticed the problem in python2.5 even though the code is unchanged.
To answer my own question, this was introduced in r64578 in ssl.py by the addition of the suppress_ragged_eofs feature (seems to originate with issue1251). While it is a change in the behavior of the ssl module, the change falls in line with other file-like objects and their handling of EOF, so the bug still falls to imaplib.
In other words, this bug appeared in 2.6 and 3.0, and is present in all subsequent versions.
Scott Dial scott+python-dev@scottdial.com wrote:
Scott Dial wrote:
While this code is present in older versions of python, it seems to have become a problem recently (2009-05-06 is the earliest report on the issue) perhaps due to a version bump of OpenSSL? I never noticed the problem in python2.5 even though the code is unchanged.
To answer my own question, this was introduced in r64578 in ssl.py by the addition of the suppress_ragged_eofs feature (seems to originate with issue1251). While it is a change in the behavior of the ssl module, the change falls in line with other file-like objects and their handling of EOF, so the bug still falls to imaplib.
In other words, this bug appeared in 2.6 and 3.0, and is present in all subsequent versions.
Thanks for bringing this up, Scott.
Bill
Scott Dial wrote:
I would appreciate this bug being resolved before the next release as it effects me on a daily basis. I have submitted a patch, which reflects my local solution.
Unfortunately, it's almost certainly too late to get this into 2.6.3. It really needed to be brought up back when Barry called for identification of significant 2.6 bugs and patches rather than after the RC had already been released.
Regards, Nick.
On Oct 1, 2009, at 7:09 AM, Nick Coghlan wrote:
Scott Dial wrote:
I would appreciate this bug being resolved before the next release as it effects me on a daily basis. I have submitted a patch, which reflects my local solution.
Unfortunately, it's almost certainly too late to get this into 2.6.3. It really needed to be brought up back when Barry called for identification of significant 2.6 bugs and patches rather than after the RC had already been released.
Right. Scott, you can get reviews and support for the patch now so that the bug can be addressed in 2.6.4.
-Barry
Nick Coghlan wrote:
Scott Dial wrote:
I would appreciate this bug being resolved before the next release as it effects me on a daily basis. I have submitted a patch, which reflects my local solution.
Unfortunately, it's almost certainly too late to get this into 2.6.3. It really needed to be brought up back when Barry called for identification of significant 2.6 bugs and patches rather than after the RC had already been released.
I understand. I didn't figure out the bug until after rc1 landed. It was only happening spuriously with my mail server, never when I manually tried to invoke the problem. I was forced to let my cronjob run until the kernel killed getmail for OOM, giving me the trace shown in the issue.
It is impossible to break anything with this patch, as no program could proceed. The 3-line patch merely converts it back into the exception that was originally raised prior to 2.6, so it's not a new behavior in that respect either. I wouldn't have anticipated this much resistance to removing an infinite loop from the standard library. I could also for this patch from the angle that it allows a remote host the ability to execute a denial-of-service attack (even by accident!) since the infinite loop appends an empty string to a list on every loop, taking CPU time and memory with it. Allow me to be naive for a moment and say, is this not the point of rc1 but to catch bugs that should not be in the final?
Of course, it's Barry's call.
On Oct 1, 2009, at 1:47 PM, Scott Dial wrote:
Allow me to be naive for a moment and say, is this not the point of rc1 but to catch bugs that should not be in the final?
Actually, no. The point of an rc is to avoid a brown paper bag mistake, i.e. something we really fscked up in the release like breaking "import sys" or the build process, etc.
We're always gonna have bugs, so that can't be it. :)
-Barry
Scott Dial wrote:
Allow me to be naive for a moment and say, is this not the point of rc1 but to catch bugs that should not be in the final?
For an x.y.0 rc I would usually agree with you, but for x.y.z (where z > 0), the intended situation is for there to be zero functional changes between the rc and the release. (This actually holds true for the final rc in x.y.0 release as well).
It's unfortunate, but the imminent point release gets people's attention in a way that the original "there is going to be a point release around this date" never seems to. If the release managers didn't draw a line and said "no more bug fixes, even minor ones" then we'd never get point releases out even close to on time.
This is particularly so for bugs that aren't a regression from x.y.(z-1) - it's most often regressions which are marked as release blockers rather than newly discovered (or analysed) bugs which have existed in the series since the x.y.0 release.
Cheers, Nick.
participants (14)
-
"Martin v. Löwis" -
Barry Warsaw -
Bill Janssen -
Brett Cannon -
Jesse Noller -
Ned Deily -
Nick Coghlan -
qwavel -
Raymond Hettinger -
Ronald Oussoren -
Russell E. Owen -
Scott Dial -
Sridhar Ratnakumar -
Zvezdan Petkovic