[Python-Dev] Stability and Change

[Skip Montanaro]

    >> > From where I sit this seems untenable, simply because what you're
    >> > proposing is going to require having three or four release managers
    >> > at the same time, each managing bugfixes and (what was the term?)
    >> > "minor features" for a previous release.  Ain't no way I'm going to
    >> > backport a change to three previous releases.

The "you" I was responding to was Guido, and his notion that several back
versions of Python code be maintained for bug fixes.  That is what I think
is untenable in the current environment.

    Andy> But that's not the point.  Who asked you to backport new features?

Nobody.  You told Guido you wanted more stability and he responded with:

    Guido> How about this as a compromise: each major release (which for
    Guido> Python is 2.0, 2.1, 2.2, 2.3 etc., never mind that only the
    Guido> "minor" digit varies -- that's how we number 'em) has a
    Guido> shelf-life of at least three subsequent major releases or 24
    Guido> months, whichever is shorter, but never less than 18 months.
    Guido> Shelf-life means that we follow up with bugfix releases (like
    Guido> 2.1.1, 2.1.2, 2.1.3) to maintain and improve stability, if
    Guido> necessary back-porting selected minor features, ...

Note the proposed committment to each major release having a preset shelf
life.  Also note the phrase at the end about possibly back-porting selected
minor features.  That's what I was responding to.

Now, I suspect you would be happier with Guido's proposal than the status
quo.  Maybe a bunch of extra people will emerge from the woodwork to
implement it, but I'm skeptical.  Guaranteeing the shelf-life of releases
for potentially two years, when PythonLabs typically releases every six
months, means you're going to have four active releases going at any one
time.  That means every bug fix that is applied to the main CVS trunk has to
at least be considered for backporting to all those other releases, maybe
not applied, but at least considered.  Practically speaking, that means you
need a release manager for each of those active releases, and they have (or
a combination of people) have to commit to that activity for two years.  As
Michael, Anthony, and others can attest, consideration of bug fixes isn't
something you can just check out every few weeks.  You get behind in a hell
of a hurry and it's a major challenge to catch up.  Right now, we are lucky
to have one or two people for a relatively short period of time who serve as
release managers for impending point releases.

    Andy> I think the solution is somewhat outside the core Python team's
    Andy> hands.  Those of us who really care about stability need to get
    Andy> together and forge the consensus that we can skip some releases;

It's more than that.  You can "select for stability" now (sounds sort of
like an aphorism you might hear in a management training course at GE).  2.0
is stable.  Has been for quite awhile.  It's not going anywhere.  If you
want to preserve it beyond when its available on the website, just mirror
it.  You could also choose 1.5.2.  It's even more stable.  However, I
presume that if you want to skip some releases you'd also like some bugs
fixed once in awhile.  If not, then I don't see the problem with the status
quo.  Latch onto a release, tell your clients you require it to run your
software, then revisit the issue every two years.

    Andy> In summary I'd like a note from Guido on the download page saying
    Andy> "we do releases every 6 months but if you prefer a longer cycle,
    Andy> go for 2.1.3 for now, and I will designate a stable 2.4.X release
    Andy> some time in 2003".  It doesn't mean 2.2 or 2.3 is bad in any way,
    Andy> but it gives us a decent planning horizon.

I don't understand how you can ask that of Guido.  You can't ask that of
Microsoft (well, you can, but you might not get an answer you like).

    Andy> Maybe EuroPython is the time to pick this up.

I expect a full report afterwards. :-)

Skip