httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <>
Subject Re: 2.0.26?
Date Thu, 30 Aug 2001 15:09:34 GMT
On Thu, 30 Aug 2001, Ryan Bloom wrote:

> > > We shouldn't do either.  If you go back and read the original thread,
> > > one of the general rules of this release strategy is that we don't
> > > release every day.  We just rolled a tarball, and announced it to the
> > > new-httpd, so there are people testing it at this point.  That tarball
> > > has to stand or fall on it's own.  In a week, we can re-roll 2.0.26, and
> > > try again.

That's silly.  That makes it very difficult to be sure we're stable again
by the time we're "allowed" to tag 2.0.26.  I agree wholeheartedly with
whomever it was that said the only problem with our current system is the
concatenation of the words "tag" and "roll" into a single "tag&roll"
operation.  We need to tag, test for just a little while to sort out the
obvious problems that have just bitten 2.0.25, and THEN roll.  Rolling
before preliminary tests are done is silly.  Half the time it means that
we don't even build on some systems, which we could have found out about
if we'd waited an hour to give people a chance to check.  I agree with
Bill that there needs to be a time limit on the duration between the tag
and the roll... four days sounds good (if not excessive).  That's what
killed 2.0.23 and 2.0.24 in a way... they took too damned long.  At least
if we spread it out over a couple days, we don't twiddle our thumbs for a
week after we realize that the tarball we just rolled is broken for some
piddly-ass reason or another.  Besides, if we wait a day or two between
the tag and the roll, there would never BE a reason to release every day,
so that problem just vanishes for free.

> And it would go a long way towards pissing off our testers.  We have people
> who download the tarball when we release it, and if we replace that tarball
> after just a few hours,

Whoa... time out.  I'm saying (and I think Bill is, too), that we *do not*
replace the tarball.  Once it's rolled, that's it.  If the tarball's
broken, try again with a new tag later.  We can easily test it for obvious
flaws ourselves between the tag and the roll.  Once *we're* satisfied,
roll it and give it to the testers.  If they're satisfied, release.

That's what we did on 2.0.22 and 2.0.23, and they very nearly made it.
2.0.24 took the re-roll-a-thousand-times approach as an approximation of
the method, and it was also close (though I seriously dislike the
re-rolling part).  But if we think that just snapshotting the tree and
then doing it again a week later is sufficient to ever get a server that's
release-quality, we're kidding ourselves IMO.

> We would easily get to a beta or production release, if we didn't keep
> changing the internals of the server, or if we posted large patches
> before they were committed, or if people ran the
> httpd-test/perl-framework test suite before committing, and if people
> would write tests once they fix a bug.  The problem we have right now,
> is that most people don't use the test-suite, so even though it is
> catching most of the bugs when they are committed, nobody knows it.

At least on this front, I'm in total agreement... the httpd-test suite is
excellent.  I've gotten to where I rely on it heavily to test any change I
make (even small ones) before committing, because it's so good at sniffing
out the subtle (and not-so-subtle) problems.  If everybody used it, we'd
be set.


   Cliff Woolley
   Charlottesville, VA

View raw message