From: "Ryan Bloom" <[EMAIL PROTECTED]>
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 [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 ;)
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
