[Python-Dev] Simple IDLE issues to commit before Python 2.7.4 release in two weeks on 4/6/2013

[Ned Deily]

In article 
<CALZ1apxb0nbcHvGf4_5Hip1bze-xuSPFp_X1GFhJQ8-frqv+jg at mail.gmail.com>,
 Todd Rovito <rovitotv at 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 of what goes in to having a good 
batteries-included experience for our users, including IDLE users.  We 
all work on Python releases because we want to do it and we like to do 
it.  That doesn't mean the process is cast-in-concrete or can't be 
improved.  But there is a cost involved in producing releases that isn't 
always readily apparent.

Specially for IDLE, I think there are a number of things we can do to 
improve and speed its development process.  As noted, I'll have some 
concrete suggestions soon but, right now, I should get back to the 
release candidates at hand.  In the meantime, let's see what we can do 
to get those patches checked in, documented, and tested.

-- 
 Ned Deily,
 nad at acm.org