[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Release Management for 1.6.x

From: <kmradke_at_rockwellcollins.com>
Date: Wed, 17 Sep 2008 09:49:38 -0500

Lieven Govaerts <svnlgo_at_mobsol.be> wrote on 09/16/2008 10:05:14 PM:
> Hyrum K. Wright wrote:
> > Hello all,
> >
> > Since the 1.5.x release process fiasco, I've been doing a lot of
thinking about
> > how to avoid that situation in 1.6.x. These are some of my ideas, and
> > ultimately they form the basis of how I'm planning on proceeding with
the 1.6.0
> > release.
> >
> ...
> >
> > Once 1.6.0-rc1 is released, I'll follow the standard soak process,
with a final
> > RC the week before release. Release Candidates should be just that:
code which
> > is ready for release, and which we'd feel perfectly comfortable
releasing as the
> > final release. Let's not have 11 "release candidates" before we find
one we can
> > actually release.
> >
> One way to avoid that is to have a clear view on when features are
> ready. Given the clearly defined time box, I propose to define some
> dates when certain checks and decisions can be made:
> I'm thinking of:
> - somewhere beginning October: look at the existing features and decide
> what needs to be done to finish them for 1.6.
> - mid October: fix the regressions introduced in trunk. A number of
> tests have been marked as XFail on trunk in the last weeks (double
> delete, tree conflicts). Some of them are due to changed behavior,
> others due to regressions.
> - continuously, end October at the latest: look at the test results of
> the buildbots and make sure all tests pass on all tested platforms
> (including serf). We could do with some more buildbots, especially for
> bdb testing.

Suppose one has access to some fairly beefy hardware on multiple
platforms (solaris x86, windows, linux) that have a fair number of
spare cycles.

What does it take to become a buildbot?

Kevin R.
Received on 2008-09-17 16:49:45 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.