httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: 2.0.26?
Date Thu, 30 Aug 2001 16:55:56 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
> > > > > 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.

Well, I was one of those people that requested you roll a tarball and that was a mistake.
It is simple enough to do a tagged cvs update.  We do not need to provide tarballs
immediately after we tag.

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

Are we really discussing the time between tag and roll now?  If an hour is not enough,
then make it a day or three. I suspect however the time between tag and roll is really not
the issue for you.  Gotta convince you that the whole notion of tagging anytime and
defering the roll for n amt of time is a good process :-) I think it is. Once you've
bought in, then we can discuss implementation details.

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

Not really. The process Cliff and I outlined is really aimed at getting -a- stable release
available. The process will take at least 2 days to go through but shouldn't take more
than maybe 4 days total. If we use this process AND use your suggestions to not commit
huge chunks of untested code during our 'stabilization period' I am confident we can get
stable releases out on almost every try. We can control the release of tarballs to the
test community.

And what is the point of having testers spend time on a release that we know is broken?
Isn't it better to just tell them "hey don't waste your time on this tarball"?.  OTOH...
what rule says that testers must test each and every tarball? If a tarball (even an alpha
tarball) works well enough, the testers can still find and report bugs that we havent
discovered yet.

One other question... have you received complaints from testers about the frequencey of
our tarball updates?

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

I don't think we are currently using the model suggested by Roy. I believe Roy's model is
closer to what Cliff and I are advocating. With one exception... The exception is that
some of us believe a 'feature freeze' (or 'big code change freeze', whatever you want to
call it) needs to go into effect during the 'stabilizing period'.  I know Roy doesn't like
this idea but I see no other way out of our current inability to get stable releases.

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

+1. Announce when we are in the 'stabilization period' and discourage (prohibit? :-) big
commits during the period that do not enhance stability.


View raw message