apr-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: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Date Sat, 05 Dec 2009 01:48:02 GMT
Joe Orton wrote:
> On Thu, Dec 03, 2009 at 05:21:09PM -0600, William Rowe wrote:
>> Paul Querna wrote:
>>> Vote Results:
>>>    +1 (binding): Sander Temme, Paul Querna, Joe Orton,  Niklas Edmundsson,
>>>    +1: Gregg Smith
>>>  +/-0: Rainer Jung
>>>     -1: William A. Rowe, Jr.
>>>
>>> Vote passes.
>> I'm sorry.  I explicitly insisted on a vote on the -deps package seperately
>> from the 2.3.4 package, because it was entirely reasonable that Sander Temme,
>> Paul Querna, Joe Orton, Niklas Edmundsson, or Gregg Smith reviewed -only- the
>> httpd-2.3.4-alpha.tar.xx package alone.
> 
> I've no issue at all with the -deps tarball containing a snapshot of 
> APR:
> 
> 1) the httpd project cannot force the APR project to commit to API 
> stability by distributing a snapshot of the APR 1.4 branch.  Why on 
> earth would that be the case?  The only time the APR project commits to 
> API stability is by making a new .0 release itself.  What other projects 
> do is irrelevant to APR.

Joe, as I pointed out in another thread, httpd *does* commit apr the moment
the mislabeled artifact hits www.apache.org/dist/ - where does that package
suggest it is nothing but a snapshot?  The answer is, it doesn't.

When we did this previously in httpd 2.0 (never 2.1 to the best of my
recollection) we actually did commit to that particular apr API.  The
rules in 0.9 just weren't so draconian.

If you don't like any of these rules;

 * what is on /dist/ is a release
 * what is released apr >= 1.0 follows absolute versioning rules
 * what is a snapshot doesn't appear on /dist/

then take those issues to an infra/board level.  We've had these discussions
a thousand times on incubator lists, and this is a clear case of what is
good for the goose...

> 2) the httpd project isn't taking on any commitment to itself maintain 
> API stability in the shipped APR snapshot because *this is an alpha*, so 
> we're not guaranteeing API stability.

Nope, much like broken ldap and crypto interfaces, it simply inflicts them
upon apr and hopes for someone else to clean up the junk later, perhaps.

But the apr project would be remiss in not voiding 1.4.x and moving on to
1.5.x for API additions since users can now be reasonably expected to have
installed an apr 1.4.x major/minor with a specific feature set.

> Furthermore I don't think it's a good idea to set a precedent of 
> requiring a separate vote on each file which makes up "the release".  I 
> certainly presumed that the vote Paul called was for all the files 
> making up "the release".

Nonsense.  I post up httpd win32 binaries all the time to /dev/dist/.  Do
I really think everyone voting on the source code snapshot of httpd is paying
any attention to that artifact (or this new -deps artifact, when all the deps
are already provisioned on most voter's machines)?





Mime
View raw message