Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <20051129040727.GC28636@scotch.ics.uci.edu>
References: <20051129015334.30793.qmail@minotaur.apache.org>
 <F9483A30-7ED3-429B-B214-1AD8E741483D@gbiv.com>
 <438BB92E.7020400@force-elite.com>
 <6C70BE14-2A04-4BEE-99DD-F8DF2573BC4D@gbiv.com>
 <20051129040727.GC28636@scotch.ics.uci.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9098E578-FD59-4F81-A58E-C83CA8099B9A@gbiv.com>
Content-Transfer-Encoding: 7bit
From: "Roy T. Fielding" <fielding@gbiv.com>
Subject: Re: svn commit: r349582 - /httpd/httpd/tags/2.2.0/
Date: Mon, 28 Nov 2005 23:24:41 -0800
To: dev@httpd.apache.org

On Nov 28, 2005, at 8:07 PM, Justin Erenkrantz wrote:

> On Mon, Nov 28, 2005 at 07:54:24PM -0800, Roy Fielding wrote:
>> What rules are you talking about?  GA just means it isn't alpha or
>> beta -- it
>> has nothing whatsoever to do with the version number.  2.2 is now our
>> STABLE
>> branch, not our GA branch.
>
> See VERSIONING.

I've seen it.  2.2.0 is our stable branch.  I believe the vote  
indicates that
the 2.2.0 release should match the code in 2.1.10 modulo the changes  
necessary
to bump the version and update the documentation.  However, nobody  
bypasses
our release voting procedure just because they committed some  
document in CVS.
Release votes are on completed, verifiable, signed source tar balls.

> What documentation are you talking about?

   ABOUT_APACHE
   CHANGES
   docs/manual/*
   INSTALL
   LAYOUT
   README
   */*/README
   include/ap_release.h
   include/ap_mmn.h (probably okay as is)

and that is just what goes inside the tarball.  We also have to  
update the
STATUS files, the website (I see Paul has started that), create  
docs-2.2,
and all of the other things people will remember as soon as we cross the
tarball threshold.

I mentioned those on our trip to Wells Fargo last week.  I would have  
fixed
them myself by now, but I made the mistake of updating my OS X 10.3.9 to
10.4.3 and Xcode 2.2 first, which led to three wasted days trying to fix
lame fink bugs instead.

>> In any case, we vote on complete source tarballs, not some
>> expectation of
>> a tag.  There can't be any 2.2.0 release votes yet because it doesn't
>> exist
>> as a released tarball, nor can it exist until we have updated the  
>> docs.
>
> Yes, and we voted on the tarball contents which would be identical to
> 2.1.10.  The only change is the release number inside ap_release.h.
> I don't consider that a material change that would alter my vote.

So if I were to go the website and cp 2.1.10.tar* 2.2.0.tar* you
wouldn't change your vote on that copy?  You wouldn't mind that the
tarball has ap_version wrong, the docs were last updated in 2002,
and we would need to do a 2.2.1 to clean that trivial stuff up?

I am not asking you to change your vote once a 2.2.0 tarball is created.
I am telling you that you can't vote on 2.2.0 until a tarball is created
that calls itself 2.2.0 and thus is available for review.  I refuse to
believe that anyone on the PMC has reviewed a release package that  
hasn't
even been packaged yet.

Feel free to veto any technical change that would cause 2.2.0 to differ
significantly from 2.1.10.  Feel free to make your vote on 2.2.0 on the
basis of a recursive diff between the two tarball packages.

> The majority of votes cast were for GA.  At least to me and Rich (and
> likely others), that implied 2.2.0.  A few people (but not enough to
> alter the majority) specifically said that they would not vote for
> 2.2.0.  -- justin

The only vote I saw was a 2.1.10 release vote and a statement of  
intention
to make 2.2.0 match the code in 2.1.10.  That does not imply 2.2.0 is  
being
released based on that vote, which is patently absurd.  If you think  
anything
in our guidelines implies such a thing, then please point it out so that
I can delete it.

....Roy