[Python-Dev] PEP 6: Patch and Bug Fix Releases

[aahz@pobox.com (Aahz Maruch)]

>> Remember that all bugfixes are available as patches off of SourceForge.
> 
> I'm sorry, Aahz, but that is just plain not true. It's not a little bit not
> true, it's very not true. A lot of the patches applied are either never
> submitted to SF (because it's the 'obvious fix' by one of the commiters) or
> are modified to some extent from thh SF patch proposed. (Often
> formatting/code style, fairly frequently symbol renaming, and not too
> infrequently changes in the logic for various reasons.)

I'm thinking one of us is confused.  CVS is hosted at SourceForge,
right?  People can download specific parts of Python from SF?  And we're
presuming there will be a specific fork that patches are checked in to?
So in what way is my statement not true?

>>> ... that would make 10+ 'releases' of various form in those 6 months.
>>> Ain't no-one[*] going to check them out for a decent spin, they'll just
>>> wait for the final version.
>> 
>> That's why I'm making the beta cycle artificially long (I'd even vote
>> for a two-month minimum).  It slows the release pace and -- given the
>> usually high quality of Python betas -- it encourages people to try them
>> out.  I believe that we *do* need patch betas for system testing.
> 
> But having a patch release once every 6 months negates the whole
> purpose of patch releases :) If you are in need of a bugfix, you
> don't want to wait three months before a bugfix release beta with
> your specific bug fixed is going to be released, and you don't want
> to wait two months more for the release to become final. (Note: we're
> talking people who don't want to use the next feature release beta or
> current CVS version, so they aren't likely to try a bugfix release
> beta either.) Bugfix releases should come often-ish, compared to
> feature releases. But maybe we can get the BDFL to slow the pace of
> feature releases instead ? Is the 6-month speedway really appropriate
> if we have a separate bugfix release track ?

Well, given that neither of us is arguing on the basis of actual
experience with Python patch releases, there's no way we can prove one
point of view as being better than the other.  Tell you what, though:
take the job of Patch Czar, and I'll follow your lead.  I'll just
reserve the right to say "I told you so".  ;-)

>>> I'm also for starting the maintenance branch right after the real release,
>>> and start adding bugfixes to it right away, as soon as they show up. Keeping
>>> up to date on bufixes to the head branch is then as 'simple' as watching
>>> python-checkins. (Up until the fact a whole subsystem gets rewritten, that
>>> is :) People should still be able to submit bugfixes for the maintenance
>>> branch specifically.
> 
>> That is *precisely* why my original proposal suggested that only the N-1
>> release get patch attention, to conserve effort.  It is also why I
>> suggested that patch releases get hooked to feature releases.
> 
> There is no technical reason to do just N-1. You can branch of as often as
> you want (in fact, branches never disappear, so if we were building 3.5 ten
> years from now (and we would still be using CVS <wink GregS>) we could apply
> a specific patch to the 2.0 maintenance branch and release 2.0.128, if need
> be.)

No technical reason, no.  It's just that N-1 is going to be similar
enough to N, particularly for any given bugfix, that it should be
"trivial" to keep the bugfixes in synch.  That's all.
-- 
                      --- Aahz  <*>  (Copyright 2001 by aahz@pobox.com)

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

Three sins: BJ, B&J, B&J