httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: 2.0.26?
Date Thu, 30 Aug 2001 16:04:45 GMT
On Thursday 30 August 2001 08:09, Cliff Woolley wrote:
> 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

That doesn't work.  The last time I tagged, and then waited to roll, I was
told that I needed to get tarballs up so that people could download them.

> 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

Waiting an hour doesn't do anything.  Most people on this list don't hack
Apache all day every day.  The whole point of the current system, is that
we tag when things all look good.  If we are wrong, then we wait a week,
and try again.

> 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.

You are still asking testers to test multiple versions.  Or, you are going back
to the 1.3 model, where we hit a code-freeze, so every developer out there
commits everything they have in their tree just before we go code-freeze.
That is the problem that killed Apache 1.3.13, 14, 15, 16.

> > 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.

You know what's funny?  When Roy suggested this model, that was the
exact argument I used to explain why it wouldn't work.  That is the
release model we decided to use though.  The point is, the developers
know best when the tree is good.  So, the developers tag it when they
think it is good.  If we as the programmers can't determine when the
tree is good, then we have some pretty big problems.

> > 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.

Yep.  :-)  But we also need to stop committing every possible change immediately.
I don't care about making changes to the server, but post the patches to
the list first, so that somebody can tag if it looks like a large patch.

Ryan 

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message