Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013
On 3/25/2013 3:30 PM, Todd Rovito wrote: http://bugs.python.org/issue7136 Idle File Menu Option Improvement http://bugs.python.org/issue17390 display python version on idle title bar http://bugs.python.org/issue17511 Idle find function closes after each find operation http://bugs.python.org/issue6699 IDLE: Warn user about overwriting a file that has a newer version on filesystem http://bugs.python.org/issue10747 Include version info in Windows shortcuts the issue is for 3.x but perhaps simple to implement for 2.7? http://bugs.python.org/issue2704 IDLE: Patch to make PyShell behave more like a Terminal interface I am waiting for 434 or an alternative to be accepted before pushing any IDLE patch. I have no interest in bikeshedding a somewhat meaningless, for IDLE, distinction between behavior and enhancement, nor in being asked to revert a patch that I tested on multiple versions. However, I might use your list to select patches for testing on Windows. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013
2013/3/25 Todd Rovito rovit...@gmail.com: Python 2.7.4 release candidate was just announced and is ready for testing here: http://python.org/download/releases/2.7.4/ Now the clock is ticking and we have two weeks to get IDLE issues pushed into CPython before the final release of 2.7.4. I'm afraid the ship has sailed on that. After a bugfix release candidate, I only take patches that fix regressions from earlier releases of the same series. (The goal is to not make any changes between the release candidate and final release.) Assuming PEP 343 becomes policy, IDLE changes can land for 2.7.5, which will be in approximately 6 months. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013
In article calz1apxb0nbchvgf4_5hip1bze-xuspfp_x1gfhjq8-frqv...@mail.gmail.com, Todd Rovito rovit...@gmail.com wrote: Now the clock is ticking and we have two weeks to get IDLE issues pushed into CPython before the final release of 2.7.4. Below is my list of low risk issues that would be great to get pushed into CPython. I hope this email will encourage CPython Core Developers to make the commits or tell us what we can do, like more testing or better documentation, to get these issues cleaned up and committed before 2.7.4 ships. Todd, Thanks for your suggestions and work to improve IDLE and Python, in general. There has been a lot of discussions recently, including your PEP proposal. I have not commented on the discussions yet, though I plan to in the next few days. Unfortunately, it comes at one of the busiest times for those of us working on releases. Not only is the 2.7.4 release in preparation but 3.2.4rc1 and 3.3.0.rc1 are about to be announced, all on similar schedules. So just a few comments from my release team perspective. No doubt, others may have other opinions. Bugfix releases, like these three, follow an abbreviated version of the full feature release process, outlined in the developer's guide: http://docs.python.org/devguide/devcycle.html#stages For bugfix releases, we typically skip alphas and betas and go right to the release candidate stage, under the assumption that the criteria used for commits added to bugfix releases are designed to avoid incompatible changes and new features, unless explicitly approved for good reasons. That means that a release candidate is meant to be just that: the final set of bits that will be released. All of us involved in software development have our own war stories of how some little last-minute change caused some unexpected breakage. So the normal expectation is that, if any change is accepted and cherry-picked after a release candidate has been published, a new RC cycle will need to happen unless the release manager decides the change is trivial enough that the risk is truly minimal, e.g. something like an obvious typo or a doc change. Certainly the changes proposed here would not normally fit those criteria. Also, before the changes could be considered to be cherry-picked for a release, they need to be applied to the branches first and given some amount of testing, preferably on all of the major platforms where we support IDLE: X11, Windows, OS X. So that's what needs to happen next. There are various developers who have been applying IDLE fixes and now Roger is able to do so as well (yay!). Once they are in, then the question of release becomes relevant. There are a couple of possible scenarios I can see. 1. It's possible that problems will show up in one or more of the current RCs, necessitating another RC cycle, at which time the release manager(s) *might* be amenable to cherrypicking one or more fixes from the current branches. 2. It's also possible (probable, I hope) that 2.7.5 and/or 3.3.2 will follow relatively quickly after 2.7.4 and 3.3.1. (3.2.4 is expected to be the final 3.2.x bugfix release before it enters security-only fix mode.) The period since the last maint releases for 2.7.x and 3.2.x was unusually long, for various good reasons, so there are about a year's worth of fixes going out for them this time, thereby raising the likelihood that new problems will be found requiring a fix in a new bugfix release. Plus there are some security issues that need a final resolution in a release. So, I'm hopeful that we won't have to wait nearly as long to see 2.7.5 after 2.7.4. There's not as long a gap since 3.3.0 but still somewhat long for a first bugfix release. BTW, there is a fair amount of activity that goes on somewhat behind the scenes with getting releases out-the-door. There a number of release artifacts that need to be produced and tested, webpages that need to be updated, announcements sent, etc. For example, for OS X, we normally release two variants of installers for each beta, rc, and final release. Between the two variants, we support 13 different architecture/os-release combinations (only 11 for 3.3.x). That means, at the moment, we have 37 different combinations we could test (including those for 2.7.4rc1, 3.2.4rc1, and 3.3.1rc1). I don't personally test every one of them but I do run the Python tests on a representative sample (various OS levels vs. ppc/Intel-32/Intel-64) of configurations, including at least very minimal manual tests of IDLE to cover things like different versions of Tcl/Tk we support on OS X and current fixes like the recent infamous preferences panel crash. Then there's the time required to investigate and writeup test failures, and decide on a fix strategy (e.g. is it a release blocker?). Similar things happen for the WIndows installers and for the main source packages. All of these things are part
Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013
On Mar 25, 2013, at 1:40 PM, Benjamin Peterson benja...@python.org wrote: ... Assuming PEP 343 becomes policy ... Are you sure you got this PEP number right? The 'with' statement? http://www.python.org/dev/peps/pep-0343/ -glyph___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013
2013/3/25 Glyph gl...@twistedmatrix.com: On Mar 25, 2013, at 1:40 PM, Benjamin Peterson benja...@python.org wrote: ... Assuming PEP 343 becomes policy ... Are you sure you got this PEP number right? The 'with' statement? Sorry, I meant PEP 434. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013
On Mon, Mar 25, 2013 at 3:57 PM, Glyph gl...@twistedmatrix.com wrote: On Mar 25, 2013, at 1:40 PM, Benjamin Peterson benja...@python.org wrote: ... Assuming PEP 343 becomes policy ... Are you sure you got this PEP number right? The 'with' statement? http://www.python.org/dev/peps/pep-0343/ Don't worry even google confuses the two :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013
On Mon, Mar 25, 2013 at 4:40 PM, Benjamin Peterson benja...@python.org wrote: I'm afraid the ship has sailed on that. After a bugfix release candidate, I only take patches that fix regressions from earlier releases of the same series. (The goal is to not make any changes between the release candidate and final release.) Assuming PEP 343 becomes policy, IDLE changes can land for 2.7.5, which will be in approximately 6 months. Benjamin, No problem we can wait 6 months. I should of read the dev guide section about Python releases before I sent the email. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013
On Mon, Mar 25, 2013 at 5:31 PM, Ned Deily n...@acm.org wrote: Todd, Thanks for your suggestions and work to improve IDLE and Python, in general. There has been a lot of discussions recently, including your PEP proposal. I have not commented on the discussions yet, though I plan to in the next few days. No problem I enjoy working on Python I look forward to reading your comments. Unfortunately, it comes at one of the busiest times for those of us working on releases. Not only is the 2.7.4 release in preparation but 3.2.4rc1 and 3.3.0.rc1 are about to be announced, all on similar schedules. So just a few comments from my release team perspective. No doubt, others may have other opinions. Bugfix releases, like these three, follow an abbreviated version of the full feature release process, outlined in the developer's guide: http://docs.python.org/devguide/devcycle.html#stages Thanks for the reference I will read it again this time more carefully. Before I sent the email I should have reviewed it so perhaps I jumped the gun a little. For bugfix releases, we typically skip alphas and betas and go right to the release candidate stage, under the assumption that the criteria used for commits added to bugfix releases are designed to avoid incompatible changes and new features, unless explicitly approved for good reasons. That means that a release candidate is meant to be just that: the final set of bits that will be released. All of us involved in software development have our own war stories of how some little last-minute change caused some unexpected breakage. So the normal expectation is that, if any change is accepted and cherry-picked after a release candidate has been published, a new RC cycle will need to happen unless the release manager decides the change is trivial enough that the risk is truly minimal, e.g. something like an obvious typo or a doc change. Certainly the changes proposed here would not normally fit those criteria. Thanks for taking the time to explain that to mefor sure I don't mean to rush the process. I do know that the Python team releases a high quality product and why change a good thing. Also, before the changes could be considered to be cherry-picked for a release, they need to be applied to the branches first and given some amount of testing, preferably on all of the major platforms where we support IDLE: X11, Windows, OS X. So that's what needs to happen next. I agree 100% so we just need to get these simple issues committed and done. It seems like now is a bad time so I can wait patiently, I don't want to be a pest but it drives me nuts that some of these issues have been fixed and they go uncommitted. More than anything I want the Python Core Developers to know that work has happened on IDLE and many times the patches simply don't get committed. I admit there are various reasons some of these IDLE issues don't get resolved but these first four are a slam dunk. Please Python Core Developers don't take offense I know everybody is busy moving the language forward which is super important, I want to gently tickle your belly buttons as a reminder only. There are various developers who have been applying IDLE fixes and now Roger is able to do so as well (yay!). Once they are in, then the question of release becomes relevant. Giving Roger commit rights will speed things up no doubt about that but he is learning the ropes and I was hoping to get these four simple issues committed and done with before 2.7.4 comes out. Knowing now that we have 6 months (instead of two weeks) relaxes me a little. There are a couple of possible scenarios I can see. 1. It's possible that problems will show up in one or more of the current RCs, necessitating another RC cycle, at which time the release manager(s) *might* be amenable to cherrypicking one or more fixes from the current branches. 2. It's also possible (probable, I hope) that 2.7.5 and/or 3.3.2 will follow relatively quickly after 2.7.4 and 3.3.1. (3.2.4 is expected to be the final 3.2.x bugfix release before it enters security-only fix mode.) The period since the last maint releases for 2.7.x and 3.2.x was unusually long, for various good reasons, so there are about a year's worth of fixes going out for them this time, thereby raising the likelihood that new problems will be found requiring a fix in a new bugfix release. Plus there are some security issues that need a final resolution in a release. So, I'm hopeful that we won't have to wait nearly as long to see 2.7.5 after 2.7.4. There's not as long a gap since 3.3.0 but still somewhat long for a first bugfix release. All this is good information and makes me feel even better about waiting a few months to get these four issues and possibly more IDLE issues fixed before the next release. BTW, there is a fair amount of activity that goes on somewhat behind the scenes with getting releases
Re: [Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013
Todd Rovito writes: All this is good information and makes me feel even better about waiting a few months to get these four issues and possibly more IDLE issues fixed before the next release. +1 for more issues fixed in the next release! :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
