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

[aahz@pobox.com (Aahz Maruch)]

>>     1. There must be zero syntax changes.  All .pyc and .pyo files
>>        must work (no regeneration needed) with all patch releases
>>        forked off from a feature release.
> 
> Hmm... Would making 'continue' work inside 'try' count as a bugfix or as a
> feature ? It's technically not a syntax change, but practically it is.
> (Invalid syntax suddenly becomes valid.) 

That's a good question.  The modifying sentence is the critical part:
would there be any change to the bytecodes generated?  Even if not, I'd
be inclined to reject it.

>>   Bug Fix Releases
>> 
>>     Bug fix releases are a subset of all patch releases; it is
>>     prohibited to add any features to the core in a bug fix release.
>>     A patch release that is not a bug fix release may contain minor
>>     feature enhancements, subject to the Prohibitions section.
> 
> I'm not for this 'bugfix release', 'patch release' difference. The
> numbering/naming convention is too confusing, not clear enough, and I don't
> see the added benifit of adding limited features. If people want features,
> they should go and get a feature release. The most important bit in patch
> ('bugfix') releases is not to add more bugs, and rewriting parts of code to
> fix a bug is something that is quite likely to insert more bugs. Sure, as
> the patch coder, you are probably certain there are no bugs -- but so was
> whoever added the bug in the first place :)

As I said earlier, the primary motivation for going this route was the
ambiguous issue of case-sensitive imports.  (Similar issues are likely
to crop up.)

>>     The Patch Czar decides when there are a sufficient number of
>>     patches to warrant a release.  The release gets packaged up,
>>     including a Windows installer, and made public as a beta release.
>>     If any new bugs are found, they must be fixed and a new beta
>>     release publicized.  Once a beta cycle completes with no new bugs
>>     found, the package is sent to PythonLabs for certification and
>>     publication on python.org.
> 
>>     Each beta cycle must last a minimum of one month.
> 
> This process probably needs a firm smack with reality, but that would have
> to wait until it meets some, first :) Deciding when to do a bugfix release
> is very tricky: some bugs warrant a quick release, but waiting to assemble
> more is generally a good idea. The whole beta cycle and windows
> installer/RPM/etc process is also a bottleneck. Will Tim do the Windows
> Installer (or whoever does it for the regular releases) ? If he's building
> the installer anyway, why can't he 'bless' the release right away ?

Remember that all bugfixes are available as patches off of SourceForge.
Anyone with a truly critical need is free to download the patch and
recompile.  Overall, I see patch releases as coinciding with feature
releases so that people can concentrate on doing the same kind of work
at the same time.

> I'm also not sure if a beta cycle in a bugfix release is really necessary,
> especially a month long one. Given that we have a feature release planned
> each 6 months, and a feature release has generally 2 alphas and 2 betas,
> plus sometimes a release candidate, plus the release itself, and a bugfix
> release would have one or two betas too, and say that we do two betas in
> those six months, 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.

>>     Should the first patch release following any feature release be
>>     required to be a bug fix release?  (Aahz proposes "yes".)
>>     Is it allowed to do multiple forks (e.g. is it permitted to have
>>     both 2.0.2 and 2.0.2p)?  (Aahz proposes "no".)
>>     Does it makes sense for a bug fix release to follow a patch
>>     release?  (E.g., 2.0.1, 2.0.2p, 2.0.3.)
> 
> More reasons not to have separate featurebugfixreleasethingies and
> bugfix-releases :)

Fair enough.

>>     What is the equivalent of python-dev for people who are
>>     responsible for maintaining Python?  (Aahz proposes either
>>     python-patch or python-maint, hosted at either python.org or
>>     xs4all.net.)
> 
> It would probably never be hosted at .xs4all.net. We use the .net address
> for network related stuff, and as a nice Personality Enhancer (read: IRC
> dick extender) for employees. We'd be happy to host stuff, but I would
> actually prefer to have it under a python.org or some other python-related
> domainname. That forestalls python questions going to admin@xs4all.net :) A
> small logo somewhere on the main page would be nice, but stuff like that
> should be discussed if it's ever an option, not just because you like the
> name 'XS4ALL' :-)

Okay, I didn't mean to imply that it would literally be @xs4all.net.

>>     Does SourceForge make it possible to maintain both separate and
>>     combined bug lists for multiple forks?  If not, how do we mark
>>     bugs fixed in different forks?  (Simplest is to simply generate a
>>     new bug for each fork that it gets fixed in, referring back to the
>>     main bug number for details.)
> 
> We could make it a separate SF project, just for the sake of keeping
> bugreports/fixes in the maintenance branch and the head branch apart. The
> main Python project already has an unwieldy number of open bugreports and
> patches.

That was one of my thoughts, but I'm not entitled to an opinion (I don't
have an informed opinion ;-).

> 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.

> And I'm still willing to be the patch monkey, though I don't think I'm the
> only or the best candidate. I'll happily contribute regardless of who gets
> the blame :)

If you're willing to do the work, I'd love it if you were the official
Patch Czar.
-- 
                      --- 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