[sugar] Release process

[Kim Quirk]

Scott,
I agree with the need for at least the four branches that you have
described below. I would think the Support team would be most familiar
with the Stable branch; the QA/Test team would do most of their work
(especially system level testing) from the Testing branch; and the
Development people would be most active on the Unstable and
Experimental branches.

One of the jobs of the release manager should be to help identify
things that are ready to move from a development branch into the
testing branch by making sure the process steps along the way are
completed, etc.

A good set of 'readiness criteria' that people agree on ahead of time
really helps when we get to each of the major decision points or
freeze points in the schedule. Then there doesn't have to be too much
arguing about whether a bug fix or feature makes the cut.

We should recognize that for our projects there may be some bug fixes
that we decide _must_ make the next release. That is usually what
causes us to delay the release (as we did with Update.1 when we
decided the fixes for Peru were more important than getting the
release out on time). We should discuss this ahead of time so it isn't
a surprise or a big disappointment to the community. We should agree
on what (if anything) could delay the release; and how the status of
those blocking items are monitored and communicated to everyone on a
regular basis.

Kim


On Fri, May 23, 2008 at 2:07 PM, C. Scott Ananian <cscott at laptop.org> wrote:
> 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/ )
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>