[sugar] Release process

[C. Scott Ananian]

On 5/23/08, Simon Schampijer <simon at schampijer.de> wrote:
>  > I'm all for not landing broken code into joyride (which makes joyride
>  > the 'testing' branch of the debian triumvirate),
>
> ? Has this something to do with #7012: olpc-update ubuntu?

No, it's just shorthand for a conversation we've had around here often:

Debian has three or four 'branches' active at any given moment:

* stable: (currently 'etch') -- the current stable branch; security fixes only.
* testing: will become the next stable branch; only "working" code.
* unstable: for development.  things are expected to work, but might not.
* experimental: for big pieces such as gnome which require
coordination, but are expected to be broken often.

EXPERIMENTAL follows the 'commit early and often' policy to allow
people to closely track upstream git/svn/cvs and adapt their code to
upstream API changes.

UNSTABLE is where most packages land first.  Packages in unstable are
expected to work, but often break things, because integration is hard.
 Still, many (most?) debian developers run unstable on their main
machines, acknowledging a willingness to encounter and report bugs as
a trade for getting new features first.  They also are helping debian
by being the 'continuous integration' guinea pigs.

TESTING.  packages are moved from unstable to testing automatically in
N days (14?) if there have been no blocking bugs filed against them in
that time period.  Thus, without explicit management, testing is far
more likely to 'just work'.  Developers who are a little less
adventurous run 'testing', and testing gets a lot of focused attention
and becomes very important in the run-up to the next stable release,
because....

STABLE.  at the point of a new debian release, the old 'testing'
branch becomes the new 'stable' branch.  No other RCs are made: the
testing branch *is* always the best RC for stable possible at a given
time.  Release management mostly involves combing the bug database for
regressions and minor bugs found in testing which were discovered
after the 14-day grace period from unstable and which haven't already
been fixed, documenting known 'wont-fix' and 'relnote' issues, and
testing upgrades and installation.  (Because of continuous
integration, most people upgrade in steps through v1, v2, v3 of a
package, and sometimes there are problems discovered when folks using
the last stable release try to upgrade directly from v1 to v3.  These
issues are tested and caught during the release process, which seeks
to ensure that stable->stable upgrades always work smoothly.)

-----

Originally, joyride was seem as the OLPC equivalent of the 'unstable'
branch (not always expected to work), and I proposed a 'killjoy'
branch for 'testing' (always expected to be our best build at a given
time).  Michael's recent proposal of stronger release management seems
to envision joyride becoming more of a 'testing' equivalent -- which
does match how we seem to be portraying the joyride builds to our
developers.  This leaves a need for a place equivalent to 'unstable'
which is less controlled: an easy place for developers to distribute
their latest stuff which is expected to work but might not.  I've also
been pushing for new features to land first on 'experimental'
equivalent branches: Dennis' FC9 is a good example here.  It's known
not to work yet, but we need to be able to distribute the
work-in-progress in order to more efficiently help push it to
completion, and to better track dependent packages (like sugar).

It may be worthwhile naming our branches to make these equivalencies clear.
 --scott

-- 
                         ( http://cscott.net/ )