From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 11:04 AM
> 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.
HuH? Ok, you rolled a tarball. Why? Our first-line testers are capable of
checking out cvs. Bump a tag (or branch), and a 30 second cvs checkout and
a < three minute make is all it takes to get testing.
> > 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.
WTF? I don't remember seeing that discussion on the list. Since oh, about 2.0.21
we've been giving folks the opportunity to test. You are the only individual who
seems to be tarring as you tag these days.
> > 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.
Not if you ever want to get anywhere. Tomcat has a good model - pay attention
to it - they get releases out the door.
> > 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 brought .14, .17, .19 and .20 out the door, as solid as we could expect them
to be under any release model. But 1.3 code is stable (if not always correct).
> > > 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,
Ryan, how many testers lists do we have? dev@httpd is _NOT_ the tarball test list.
The order must go
1. Tag. Announce as version candidate at [EMAIL PROTECTED]
2. wait for folks to build and regress (24 hours???)
3. vote. Is the feedback [at least] alpha quality? Are there no beta showstoppers?
4. bump subrevision to -alpha [optional - but I think we need to go here]
5. Tar. Announce as beta candidate at [EMAIL PROTECTED]
6. wait for folks to build, regress, and stress (72 hours???)
7. vote. Is the feedback [at least] beta quality? Are there no release
showstoppers?
8. bump subrevision to -beta [optional - but I think we need to go here]
9. Tar. Announce as release candidate at [EMAIL PROTECTED]
10. wait for folks to build, regress, and further stress (one week???).
11. The Adventuous may experiment with installing to production on non-critical
servers.
12. vote. Is the feedback of release quality? Are there no new showstoppers?
14. bump subrevision to -gold.
15. Tar. Up to www.apache.org/dist/. Broadcast the release
There will be no changes to a -gold release, ever. We could subversion the -alpha and
-beta versions, e.g. 2.0.25.nnnn-alpha. I propose the number of days since the
official
release of Apache 1.0 ;)
> > 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 every other RM has done in the recent past. If it's not spelled out
in the release docs (rolling the tarball) then someone better write up our 'new'
procedures so it's clear to everyone, and we can vote on the changes going into
that release stratagy.
> > 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.
Of course we do. "Ask." Or tag, then ask. If the answer is "no" pull the tag,
and apply it when it's ready. If it's just one file that wasn't quite there,
bump the tag.
> > > 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.
Since apxs is so totally borked that it cannot run on httpd-2.0/win32 (unlike
apache-1.3)
that is mildly difficult in some quarters. I've specifically introduced the cygwin
support
to allow me to build httpd-test. We will see how this goes.
> 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.
Ahhh... er, so it's ignored? When was the last time you reviewed a non-thread,
non-pool, non-mpm issue, Ryan?
Folks are spending alot of time on their platforms, getting things right. They aren't
reviewing one another's work. We are all guilty on this count.
Further, we are in C-T-R mode the last time I noticed.
If you want patches before big commits, then fine, we tag pre_that_big_patch. If we
agree,
lower case tags can be dropped in, and pulled out, when convenient.
That has nothing to do with the issue at hand. If you are addressing this to me,
personally (as I believe you are) you may go blow it out your <>. The patches I've
been commiting address fundemental flaws in the server architechture that have
exposed over and over again holes in our negotation stratagy. The fact that the
filter model is non-existent for user configuration (and the fact that your original
code blew up conf->pool) doesn't help either. These patches had to get in before
the server would be worthy of 'beta' status anyways. Certainly converting mod_mime
to a hash makes the other key whiner of "we've got to get this out the door" look
equally foolish. That patch ate a week of several people's lives. I hope the
performance improvement proves worth it.
The mod_mime fiasco proves that nobody has built with APR_POOL_DEBUG in quite some
time. Try it, you discover lots of useful things about mis-merge and
mis-configuration.
I've had a patch out there for, what, four weeks now to add a string to the
apr_pool_create
function with the filename and line? Nobody reviewed, nobody commented. And if nobody
is reviewing our debugging code, then who's reviewing mainline code?
Had you personally taken the time to review recent patches, perhaps you would have
known
the server wasn't ready to tag at that moment.
I'm asking key architechture questions to the list, and only about three of us are even
participating in that discussion. As long as that's true, I don't expect a release
this year unless I follow c-t-r to underlying opportunities for future exploits to
appear.
Bill
