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