httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: 2.0.26?
Date Thu, 30 Aug 2001 18:10:24 GMT
From: "Ryan Bloom" <>
Sent: Thursday, August 30, 2001 8:57 AM

> On Thursday 30 August 2001 06:38, Bill Stoddard wrote:

> > Completely agree that our release strategy (with Dr. Evil quotes around
> > strategy) is broken.  But we should be able to tag the tree anytime, IMHO.
> > If HEAD is good, I am for tagging 2.0.26 and testing it but let's not roll
> > the tarball. Fix any problems in 2.0.26 and bump the tag on affected files.
> > When we are satisfied, roll 2.0.26. Put a time limit on the whole process
> > of say, 4 days. If the time limit is exceeded (showstopper problems have
> > not been driven out within 4 days of the tag) or the rolled tarball has
> > showstoppers, consider the beta effort a failure and move on.

I'd say scope, over time.  If two platforms are 'touchy' about the build, and there
is a three line patch to get those to build, then we do it.  If there is a segfault
we can close (say J. Trawick's fix of my oops last night) then we close it.

I'm going to suggest a simple, absolute rule.  If a .h file changes (even a generated
one) then the tag is deep six-ed.  If the httpd-std.conf file changes, it's axed.  
And if the syntax parsers change, it's axed.  Anything in between is our call.

I'm going to suggest we branch every release as APACHE_2_0_nn once we apply any patch
out-of-sequence (from HEAD).  E.g., I commit a feature after HTTP_2_0_30 is tagged.
Then someone notices a rare segfault dating to 2.0.12.  Well, That patch goes in, but
if it needs to be dropped on HTTP_2_0_30, then we branch with the original APACHE_2_0_nn
tag.  Anyone who checks out from cvs co -r APACHE_2_0_nn has the authoritative, current

And I suggest we go to r-t-c on following any tag.  I'm not suggesting r-t-c on the
main branch, since there aren't enough people following some obscure aspects of the
server to comment (in a timely manner.)  But once it's tagged - 3 +1's before patching
(or even bumping) a tag!

> > This is basically what we did with 2.0.24 and it was almost successful.
> > 2.0.24 dragged on a bit too long (over a week) and we rolled a couple of
> > different 2.0.24 tarballs, which was not cool. Tagging a good HEAD,
> > incrementally fixing showstoppers (provided the fixes are relatively
> > limited in scope and simple) and bumping the tag on affected files, and
> > exercising a little disipline and restraint for a few days (even just a few
> > hours) prior to our target for rolling a beta would go a long way to
> > solving this problem.
> 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, then we are basically telling them that we don't need
> their input, and they are only useful if they actually follow new-httpd, which
> I think we all know is INCREDIBLY hard to do most days.

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
  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
  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
 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  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 ;)

Take a page from the Jakarta project - their release schema works.

> tag and roll and test.  If that one isn't good enough, then we do it again a week
> later.  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.

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.


View raw message