Bug fix releases

[Aahz Maruch]

In article <mailman.983646726.27322.python-list at python.org>,
Guido van Rossum  <guido at digicool.com> wrote:
>Aahz writes:
>>
>> I think so, yes, on that latter clause.  I think perhaps it wasn't clear
>> at the time, but I believe that much of the yelling over "print >>" was
>> less over the specific design but because it came so close to the
>> release of 2.0 that there wasn't *time* to sit down and talk things
>> over rationally.
>
>In my eyes the issues are somewhat different: "print >>" couldn't
>possibly break existing code; nested scopes clearly do, and that's why
>we decided to use the __future__ statement.
>
>But I understand that you're saying that the community has grown so
>conservative that it can't stand new features even if they *are* fully
>backwards compatible.

Then you understand incorrectly.  There's a reason why I emphasized
"*time*" up above.  It takes time to grok a new feature, time to think
about whether and how we should argue in favor or against it, time to
write comprehensible and useful arguments.  In hindsight, I think you
probably did make the right design decision on "print >>", no matter how
ugly I think it looks.  But I still think you made absolutely the wrong
decision to include it in 2.0.

>So that relegates us at PythonLabs to a number of things: coding new
>modules (boring), or trying to improve performance of the virtual
>machine (equally boring, and difficult to boot), or fixing bugs (did I
>mention boring? :-).
>
>So what can we do for fun?  (Besides redesigning Zope, which is lots
>of fun, but runs into the same issues.)

Write new versions of Python.  You've come up with a specific protocol
in a later post that I think I approve of; I was trying to suggest a
balance between lots of grunt work maintenance and what I see as
perpetual language instability in the absence of any bug fix releases.

>Your math at first confused the hell out of me, but I see what you
>mean.  You want us to spend time on 2.0.1 which should be a bugfix
>release for 2.0, while at the same time working on 2.1 which is a new
>feature release.

Yup.  The idea is that because it's always an N and N-1 pair, the base
code is the same for both and applying patches to both should be
(relatively speaking) a small amount of extra work.  Most of the work
lies in deciding *which* patches should go into N-1.

>Guess what -- I am secretly (together with the PSU) planning a 2.0.1
>release.  I'm waiting however for obtaining the ownership rights to
>the 2.0 release, so we can fix the GPL incompatibility issue in the
>license at the same time.  (See the 1.6.1 release.)  I promise that
>2.0.1, unlike 1.6.1, will contain more than a token set of real
>bugfixes.  Hey, we already have a branch in the CVS tree for 2.0.1
>development!  (Tagged "release20-maint".)

Yay!  (Sorry, I'm not much of a CVS person; the one time I tried using
it, I couldn't even figure out where to download the software.  Call me
stupid.)

>We could use some checkins on that branch though.

Fair enough.

>> This means that each feature-based release gets one-and-only-one pure
>> bugfix release.  I think this will do much to promote the idea of Python
>> as a stable platform for application development.
>
>Anything we can do to please those republicans! :-)

<grin>

>> There are a number of ways I can see this working, including setting up
>> a separate project at SourceForge (e.g. pythonpatch.sourceforge.net).
>> But I don't think this will work at all unless the PythonLabs team is at
>> least willing to "bless" the bugfix release.  Uncle Timmy has been known
>> to make snarky comments about forever maintaining 1.5.2; I think this is
>> a usable compromise that will take relatively little effort to keep
>> going once it's set up.
>
>With the CVS branch it's *trivial* to keep it going.  We should have
>learned from the Tcl folks, they've had 8.NpM releases for a while.

I'm suggesting having one official PythonLabs-created bug fix release as
being a small incremental effort over the work in the feature release.
But if you want it to be an entirely community-driven effort, I can't
argue with that.

My one central point is that I think this will fail if PythonLabs
doesn't agree to formally certify each release.

>> I think one key advantage of this approach is that a lot more people
>> will be willing to try out a beta of a strict bugfix release, so the
>> release N bugfixes will get more testing than they otherwise would.
>
>Wait a minute!  Now you're making it too complicated.  Betas of bugfix
>releases?  That seems to defeat the purpose.  What kind of
>beta-testing does a pure bugfix release need?  Presumably each
>individual bugfix applied has already been tested before it is checked
>in!  

"The difference between theory and practice is that in theory, there is
no difference, but in practice, there is."

I've seen too many cases where a bugfix introduced new bugs somewhere
else.  Even if "tested", there might be a border case where an
unexpected result shows up.  Finally, there's the issue of system
testing, making sure the entire package of bugfixes works correctly.

The main reason I suggested two betas was to "lockstep" the bugfix
release to the next version's feature release.

>Or are you thinking of adding small new features to a "bugfix"
>release?  That ought to be a no-no according to your own philosophy!

That's correct.  One problem, though, is that sometimes it's a little
difficult to agree on whether a particular piece of code is a feature or
a bugfix.  For example, the recent work to resolve case-sensitive
imports could be argued either way -- and if we want Python 2.0 to run
on OS X, we'd better decide that it's a bugfix.  ;-)

>> If there's interest in this idea, I'll write it up as a formal PEP.
>
>Please do.

Okay, I'll do it after the conference.  I've e-mailed Barry to ask for a
PEP number.
-- 
                      --- Aahz (Copyright 2001 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

Nostalgia just ain't what it used to be