httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: 2.0.26?
Date Thu, 30 Aug 2001 18:10:24 GMT
From: "Ryan Bloom" <rbb@covalent.net>
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
candidate.

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 dev@httpd.apache.org.
  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 current-testers@apache.org
  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 stable-testers@apache.org
 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 ;)

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.

Bill




Mime
View raw message