>> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4