[Python-Dev] Re: Bug fix releases

Mats Wichmann xyzmats at laplaza.org
Sun Mar 4 20:59:15 EST 2001


Whew...

Let me shift out of lurk mode and put in a couple of comments.

I think on the whole a large and varied user community such as
Python's would be well served by having the /possibility/ of
maintaining several release lines - with bug fixes and possibly minor
feature additions (controversial) being issued for an older line.

Some folks DO clearly want bug fixes without having to do a major
upgrade.  Sometimes you're kind of stuck: you're delivering an
application that's well tested on one version and the risk of
switching to another version just to pick up a fix for one annoying
bug is not worth it.  Sometimes there's a good reason why a fix can't
be backported into an older Python version, but often there isn't,
other than time/manpower/motivation/etc.  The rest of us should be
able to supply that if we really want something.

The main preparatory step happened when the source went into a public
CVS repository.  Now what's needed is enough demand == submitting the
fixes, and the maintainer who will make it happen.

I can't see that this will actually happen until there's a champion
who will handle the "boring stuff" - that is, babysit the older
released line (we don't all think that's boring work, but what the
heck).  If I can point at the Linux kernel development (don't anybody
gack now), Linus handles the "interesting stuff" - the latest branch;
when it reaches a certain degree of stability he hands over to Alan
Cox.  Did Aahz just volunteer to be our Alan Cox?

I think a little historical check is also in order:  the current state
may not be indicative of the future.  The licensing issue/GPL dispute
came at a time when record numbers of folks were using Python because
they got it "for free" with Linux distributions such as Red Hat and
Mandrake, who made it hard to upgrade by not packaging up new versions
of Python in the RPM format (which, of course, users of those systems
are told is "the" way to install software.  Not everybody who uses
Linux today is interested in rebuilding from source.  To insert a
subtle dig, the source tarball has tended to autoconfigure a
not-especially-useful configuration which you have to tweak a fair bit
in the modules directory. (Didn't I hear that 2.1 is taking a more
automated approach to working out what's supportable on the target?
Yay!  My recent Solaris/x86 build was a bit, er, painful).

Not to say that the rustling all comes from the Linux world.

On the whole, things have been remarkably compatible, but the long
life of 1.5.2 caused an artifical strange situation.


Do we need to limit to "no more than one bugfix release"?  Do we need
to have "official blessing from PythonLabs"?  For me, the answer is no
to both.  If you need a fix, you need a fix.  Having problems, if they
appear, taken care of in a timely manner isn't going to hurt Python's
reputation. If there's a maintainer who is trusted, known to be
careful about what patches are accepted, insures that the right test
cycle has happened before it's declared final, I don't think most
people would have a problem with it.  Such a maintainer isn't going to
let Python slip into a mode where releases have a dozen incremental
bugfix dot-releases (not that the high quality of Python seems to
require anything like that anyway). Feel free to disagree.


-- Mats Wichmann




More information about the Python-list mailing list