From: Rui Miguel Silva Seabra (rms@1407.org)
Date: Thu Apr 25 2002 - 18:34:42 EDT
I fully agree with you, David.
On Thu, 2002-04-25 at 22:14, David Chart wrote:
> On Thu, 2002-04-25 at 18:28, Mike Nordell wrote:
> > Paul Rohr wrote:
> > > Discovering bad bugs at step 3 is a clear indicator that the release was
> > > *not*, in fact, ready for prime time.
> >
> > Indeed. Would it be feasible to create a "test" release before major
> > releases? It would obviously be a greater burden for all, and it would
> > probably create "test2" and so on releases, but it would probably iron out
> > the "obvious" bugs.
> >
> > Since I really don't know how much effort goes into a full release-cycle
> > it's possible this idea is in reality not possible.
> >
>
> I think the release process itself has, in the past, been far too quick.
>
> For the 0.99, 0.9, and 0.7 series, I don't think this was a serious
> problem. They were *supposed* to be development releases. Serious bugs
> were to be expected. For the 1.0 series, however, I think we need to
> slow down a bit.
>
> So, I suggest the following:
>
> 1) One of the core developers decides it's time to tag a release, just
> as happens now. Consensus is built, and it happens.
>
> 2) CVS is branched as 1.0.xrc1. New commits do not go into the release
> branch.
>
> 3) People test the release candidate. They make sure they can build
> binaries on their systems, and that they can do normal stuff. A standard
> test suite would be good, an automated standard test suite even better.
> Allow about a week for this.
>
> 4) If there are any showstopper bugs in rc, fix them and check the fixes
> into the branch. Nothing else goes into the branch. Not even dead simple
> fixes for other bugs. rcn+1 is tagged in the branch. Return to step 3.
>
> 5) If there are no showstopper bugs, the branch gets retagged as 1.0.x,
> and the release is announced. All the binaries already exist, so we can
> release quickly. Since a week has passed since the last commit was made,
> the Changelog is up to date. (I get time to do it at least once a week
> under normal circumstances.)
>
> This, of course, needs a definition of showstopper. Suggestions:
>
> a) Doesn't build dist. Obviously.
> b) Crash on core function. Opening a standard .abw document, for
> example. We'd need a list of these in the test suite.
> c) Dataloss on core function. The bug in, er, 0.99.2 or so which
> resulted in all style information being lost on save would be an
> example.
>
> I think that, most of the time, rc1 would end up being the release,
> since most past releases have met this standard. About 25% of the time,
> there'd be an rc2, but Abi's generally pretty solid, so I wouldn't
> expect rc3 to be very common.
>
> This might also give me time to write proper release notes, rather than
> just updating the changelog.
>
> Comments?
>
> --
> David Chart
-- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Ghandi + So let's do it...?
This archive was generated by hypermail 2.1.4 : Thu Apr 25 2002 - 18:36:53 EDT