Date: Sun, 16 Nov 1997 21:58 -0400
From: COAR@PROCESS.COM (Rodent of Unusual Size)
Message-Id: <009BD66332777470.68D8@PROCESS.COM>
To: new-httpd@apache.org
Subject: Re: Possible suggested schedule for 1.3b3
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

>From the fingers of Marc Slemko flowed the following:
>
>On Sun, 16 Nov 1997, Jim Jagielski wrote:
>
>> Here's my plan... +1s or -1s?
>> 
>>     1. Rename 1.3b3-dev to 1.3b3-fc1.
>>     2. Announce a freeze on all commits to the code tree
>>     3. Expect people to update their CVS tree, compile and
>>        test for some time (24hours) to appease Marc
>>        (note: I've been saying that people should be
>>        doing this in anticipation of the release... For
>>        some reason this does not appear to have been
>>        enough.)
>>     4. Rename 1.3b3-fc1 to 1.3b3, and tag it
>>     5. We roll, announce release
>
>I don't understand why this is necessary.  For the past dozen releases,
>barring a few exceptions where it has been skipped with poor results, the
>policy has _ALWAYS_ been to tag it, put a tarball up in a non-public
>place, then wait a day or so.  This has found problems, not only with the
>code but also with the making of the tarball (which can NOT be found out
>any other way) numerous times.

    One of Jim's points is that the "non-public" places chosen in the
    past.. erm, well, haven't been.  And I don't see any way around that
    without seeming elitist somehow (like putting it on Taz with access
    only to the CVS list).

>This is nothing new.  It has been discussed and decided on in the past. 
>Why is it suddenly a problem? 

    "Old" is not necessarily "good," any more than "new" is necessarily
    "better."

>I'm not sure there is any point in changing the version to 1.3b-fc1 or
>anything; I have seen no need for this in the past.

    Nor I..

>                       But no matter what you do, there are far too often
>problems that arise between than and between the tarball.  It simply makes
>sense to give people a chance to go over the tarball before release; how
>am I supposed to support release of a tarball that I have never seen?

    This is a valid point, I think - although it didn't work for 1.3b2;
    no-one noticed the CVS directories got included.  And if there's a
    problem with the tarball after announcement, well, we do what lots
    of other groups do: create a corrected tarball and post a message
    about it to the usual places.  The code is what matters, not the
    kit.  The content we *need* to be good, the delivery mechanism we
    just *want* to be good.

    Basically, everyone had a chance to step up and be release manager
    for this, and Jim's the only one that did.  So I think it behooves
    the rest of us to shut up and do things his way as a rule of thumb.
    If we've got constructive suggestions, good - air them.  If we think
    something is out-and-out wrong, we should speak up.  But for things
    that are matters of judgment, I think the RM should make the final
    decision.

    Personally, I'd like to see 1.3b3 named, tagged, and rolled right
    now, the version updated to 1.3b4-dev, and followed by a 24-hour
    commit freeze and testing period of the frozen code (and the
    tarball), followed by release on Tuesday if no problems surface.
    But that's just me, and I'm not the RM.

    #ken    P-)}