[Python-Dev] Community buildbots (was Re: User's complaints)

[Giovanni Bajo]

skip at pobox.com wrote:

>     Greg> Maybe there could be an "unstable" release phase that lasts
>     for a Greg> whole release cycle. So you'd first release version
>     2.n as Greg> "unstable", and keep 2.(n-1) as the current "stable"
>     release. Then Greg> when 2.(n+1) is ready, 2.n would become
>     "stable" and 2.(n+1) would Greg> become the new "unstable".
>
> In GCC don't they do an odd (stable)/even (unstable) release
> schedule?  Same for Linux kernels?  Would that help?

No. Linux kernel releases are more aggressive because of the fact that all
the patches are mostly developed in different branch/repositories and get
merged when they are already well tested and incorporated. Linus can merge
literally hundreds of patches daily into his *stable* tree, and do releases
from it even weekly, because most destabilizing works are being done in
large branches carried on for months before they even are evaluated for
being merged; or because patches were settled in the -mm tree for months.
Linus' tree is kind-of a release branch, with the difference that he is the
BDFL and does what he wants with his tree :) To keep this into perspective,
remember also that they don't have *any* kind of testsuite (nor a debugger,
if I might say).

GCC has a more "old-fashioned" release process, where the trunk evolves
through 3 stages: Stage 1 is open for all kind of changes (eg: from simple
polishing/refactoring, to merging of large branches containing work of
several man-years). Stage 2 is still open for new features, but not for big
merges. Stage 3 is feature-freezed, bug-fixing only. Then, the trunk is
branched into the new release branch, and the trunk gets back to Stage 1.
Nominally, a stage lasts 3 months, but Stage 3 often stretches up to 6
months.

The release branches are open for *only* regression fixes (that is, fixes
that correct things that used to work in previous releases but do not work
anymore). Any regression fix (with a corresponding Bugzilla entry, where
it's marked and confirmed as "regression") is applied to trunk *and* the
open release branches where the regression exists. For convoluted or
dangerous regression fixes, usually maintainers prefer to wait 1 week for
the patch to settle down on the trunk before applying it to the release
branches. The release manager pulls dot releases from the release branch.
Usually, the first release (.0) happens 3-4 months *after* the release
branch was created, that is after several months of regression-only patches
being merged to it (while new work is being done on the trunk in parallel,
in its aggressive Stage 1).

The 3-Stage work in the trunk is streamlined by the release manager. At the
beginning of Stage 1, a detailed techinical list of on-going "projects" (new
features) is presented to the mailing list, explaining the current status of
the work and its ETA, and the release manager then publishes a work-plan for
Stage 1 and 2, telling which projects will be merged when. This avoids
multiple large projects to hit the trunk at the same time, causing may
headaches to all the other developers. The work-plan is managed and updated
in the GCC Wiki (which is off-line right now, but I'll post a link as
example when it's back).
-- 
Giovanni Bajo