Release process

[Jim Gettys]

I will note that "testing" in Debian wasn't a good place to live for a
very long time: it didn't get timely security updates, and consequently,
no one ran it (so it got minimal testing, despite its name).

I believe Debian has fixed this...  We must avoid a similar issue.
                            - Jim


On Fri, 2008-05-23 at 15:17 -0400, Kim Quirk wrote:
> 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
> >
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child