You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Sander Striker <st...@apache.org> on 2005/03/06 14:22:46 UTC
Re: [VOTE] 2.1.3 as beta
Justin Erenkrantz wrote:
> 2.1.3 tarballs at: <http://httpd.apache.org/dev/dist/>
>
> I'd like to get enough votes for 2.1.3 to be a beta and commence the
> feature freeze towards a 2.2.0 GA.
>
> As we discussed at ApacheCon in November (over three months ago), this
> would mean we create a 2.2.x branch from the 2.1.3 tag and bump trunk to
> 2.3.0.
Given the fixes on trunk that went in since 2.1.3, I'd like to see a
2.1.4, and branch off of that. I'll even volunteer to take care of
T&R'ing 2.1.4 upcoming thursday.
I feel this takes care of the mod_dav exports issue as well.
> By this point, I think that if a super-cool feature hasn't made it in
> yet, it's time to admit that the feature missed the boat and it needs to
> wait until 2.4. I'm tired of waiting for 2.2 when there are excellent
> features in our trunk that are being held up for non-existent patches.
+1. I've been one of the people causing the holdup with my preference
of getting the AAA user authentication/group membership split in 2.2.
Let's not have wishful thinking keep up 2.2.
I assume we are in agreement that the current AAA discussion shouldn't
hold up moving to 2.2 either.
Sander
Re: [VOTE] 2.1.3 as beta
Posted by Graham Leggett <mi...@sharp.fm>.
Paul Querna wrote:
> I think it should be hacked into mod_authnz_ldap, and if it works, then
> work can be done to generalize it to all the authnz modules. Right now
> we really don't know what is required to get it done. It is all just
> mailing list talk and theory.
The trouble is that any work hacking it into mod_authnz_ldap isn't the
kind of work that can be extended to other modules, it will simply be a
hack into mod_authnz_ldap. Yes, we can then extend the same hack into
the other modules, but then we're just duplicating functionality across
modules that should be common.
Regards,
Graham
--
Re: [VOTE] 2.1.3 as beta
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, March 7, 2005 5:37 PM -0600 "William A. Rowe, Jr."
<wr...@rowe-clan.net> wrote:
>> ++1 - and I've always agreed. My only question is does the new API
>> make it impossible to do simple things.
...
> If the new API makes things more difficult, it's a regression.
> This AAA provider discussion just offers us the opportunity to
> really evaluate the usefulness of the new API, are things going
> to be better or worse when you want to do something beyond add
> a single-use provider.
>
> And maybe the API doesn't interfere in which case we prove that
> the new API doesn't hinder development, but promotes it. We
> already know the new API makes it simpler to implement SQL, ODBC
> or other back ends folks care to create or port to 2.2
Considering that the AAA rewrite we have today does not change *any*
existing AAA APIs that were in 2.0, but only adds APIs - I find it
extremely hard to believe that 2.1 can not do things that 2.0 could. --
justin
Re: [VOTE] 2.1.3 as beta
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:21 AM 3/7/2005, Paul Querna wrote:
>I disagree. The current authentication in 2.1 is far far better than what 2.0 has. I have been using it in production variations for over 2 years now. Just the ability to use any authentication backend with Digest is a huge improvement.
>++1 - and I've always agreed. My only question is does the new API
>make it impossible to do simple things.
>
>I believe the best method is to attack it at the point of least work, and if it ends up being good, look at extending it to everything.
>
>I think it should be hacked into mod_authnz_ldap, and if it works, then work can be done to generalize it to all the authnz modules. Right now we really don't know what is required to get it done. It is all just mailing list talk and theory.
Ok, I'd seriously disagree :) mod_authnz_ldap is already
difficult enough to follow, keeping it as fundamental as it is
today, and extending this externally, ensures we don't add bugs
to _ldap just as we want to release a beta.
>I do not believe it is appropriate to threaten a -1 veto on 2.2.0 for this issue.
Whoops - I never said veto to 2.2 (I don't think) ... you can't
veto a beta. You vote, and it's majority rule on releases (and
always has been.) Minimum 3 +1's, more +1's than -1's.
>Its not a regression, its not something we have a patch for, its something that didn't exist a week ago.
If the new API makes things more difficult, it's a regression.
This AAA provider discussion just offers us the opportunity to
really evaluate the usefulness of the new API, are things going
to be better or worse when you want to do something beyond add
a single-use provider.
And maybe the API doesn't interfere in which case we prove that
the new API doesn't hinder development, but promotes it. We
already know the new API makes it simpler to implement SQL, ODBC
or other back ends folks care to create or port to 2.2
Bill
Re: [VOTE] 2.1.3 as beta
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> At 07:22 AM 3/6/2005, Sander Striker wrote:
>
>>I assume we are in agreement that the current AAA discussion shouldn't
>>hold up moving to 2.2 either.
>
>
> Absolutely it does. Either 2.1-dev has made implementing this
> worse (my essentially workable proposal for 2.0 would no longer
> work at all, with no workaround) or 2.1-dev has made implementing
> such a feature possible, even trivial, even if it's not part of
> the httpd-2.2 core. Suggesting we push out 2.2 'as is, whatever'
> would be like having shoved out either Ryan's or Greg's original
> filter stack without the group coming to concensus (and best of
> breed solution.)
>
> I'm not saying we need to have this module. I'm asking if our
> new auth framework is worse or better than yesterday's for folks
> to build upon it.
I disagree. The current authentication in 2.1 is far far better than
what 2.0 has. I have been using it in production variations for over 2
years now. Just the ability to use any authentication backend with
Digest is a huge improvement.
> I'm sensing from comments that we've created a more complex
> structure which is harder to work with, but might not quite solve
> real world problems. If that's true (I'm +/-0 on deciding until
> I work this into 2.1-dev auth) then I'm one -1 on 2.2.0.
>
This whole discussion is about a feature that has never existed before,
and there isn't a patch for it yet.
I believe the best method is to attack it at the point of least work,
and if it ends up being good, look at extending it to everything.
I think it should be hacked into mod_authnz_ldap, and if it works, then
work can be done to generalize it to all the authnz modules. Right now
we really don't know what is required to get it done. It is all just
mailing list talk and theory.
I do not believe it is appropriate to threaten a -1 veto on 2.2.0 for
this issue. Its not a regression, its not something we have a patch
for, its something that didn't exist a week ago.
> The point to 2.2 is we are doing things that 2.0 couldn't. Either
> we have added such things well, or poorly. Only alphas in the
> hands of module authors tell us the answer to this. [For that
> matter, something somewhere needs to attract our module community
> to investigate, I don't think we successfully have engaged them.
> Not even some high level "what's changed" exists today other than
> good old CHANGES.txt.]
Alphas are generally worthless, as they are currently released, imho.
We need to get to 'beta' and put it on our front page, get slashdotted,
and send out announcement emails.
> That said - -nothing- should ever hold up 2.1.x alpha anytime
> someone has the energy to run with the ball!
I am discouraged from trying to RM one, just from the knowledge that it
will get a -1 veto, before I even roll it.
-Paul
Re: [VOTE] 2.1.3 as beta
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:49 AM 3/8/2005, Sander Striker wrote:
>William A. Rowe, Jr. wrote:
>
>>Onward to 14 ++1 to Sander's efforts to roll out 2.1.4 ... let's get it right (at least, let's have something that builds,
>>irrespective of it has the features folks want.)
>
>So what is failing to build? 2.1.3? Or trunk? Only on
>win32, or on other platforms as well? Can you reproduce?
AFAIK win32 builds, I'll verify tonight. Have one odd emit about
the pcre stuff, but it doesn't look to be a showstopper.
Actually, one of my bigger beta concerns was picking up this update
to pcre. Looks like now, we can.
>>I've chided tomcat-dev to bother to report to us what their Gump
>>results are. Would go a long ways to solving a problem we didn't
>>know exists.
>
>It seems to build fine in the ASF wide Gump run on brutus:
>
> http://brutus.apache.org/gump/public/apache-httpd/index.html
Here is Bill Barker's report;
http://issues.apache.org/bugzilla/show_bug.cgi?id=32787
Re: [VOTE] 2.1.3 as beta
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:22 AM 3/8/2005, Justin Erenkrantz wrote:
>Note that 2.1.3 fails to build on Win32 because APR 1.1.0 doesn't build.
>
>This Win32 failure is *not* an httpd problem. Mladen reported that using
>APR trunk worked fine with 2.1.3.
Perhaps you aught to respond to the dev@apr post;
Subject: 1.2? Fixes to libapr[util...].dll version resource
Message Id: <6....@pop3.rowe-clan.net>
rather than debate it here where it's off topic?
Believe me, something I have already considered and am concerned
about - and would like to see addressed (and help address).
Re: [VOTE] 2.1.3 as beta
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Mar 08, 2005 at 08:49:52AM +0100, Sander Striker wrote:
> So what is failing to build? 2.1.3? Or trunk? Only on
> win32, or on other platforms as well? Can you reproduce?
Note that 2.1.3 fails to build on Win32 because APR 1.1.0 doesn't build.
This Win32 failure is *not* an httpd problem. Mladen reported that using
APR trunk worked fine with 2.1.3.
The Win32-savvy APR developers need to figure out what's wrong and help us
backport the changes to APR 1.1.x and help us release 1.1.1. (IMHO, with my
APR hat on, releasing 1.2.0 is not an option for APR as apr_dbd isn't ready.)
I and others have repeatedly said that we refuse to tie *any* httpd release to
a non-released version of APR. And, I don't like to see httpd -1ed because
APR screwed something up. -- justin
Re: [VOTE] 2.1.3 as beta
Posted by Sander Striker <st...@apache.org>.
William A. Rowe, Jr. wrote:
> jakarta-tomcat-dev reports Gump can't build, but since they
> haven't given us details so not much we can do about it.
>
> Fails to even build on Win32.
>
> -1 for beta on 2.1.3.
I think we passed the 2.1.3 station already.
> Onward to 14 ++1 to Sander's efforts to roll out 2.1.4 ...
> let's get it right (at least, let's have something that builds,
> irrespective of it has the features folks want.)
So what is failing to build? 2.1.3? Or trunk? Only on
win32, or on other platforms as well? Can you reproduce?
> I've chided tomcat-dev to bother to report to us what their Gump
> results are. Would go a long ways to solving a problem we didn't
> know exists.
It seems to build fine in the ASF wide Gump run on brutus:
http://brutus.apache.org/gump/public/apache-httpd/index.html
Sander
Re: [VOTE] 2.1.3 as beta
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
jakarta-tomcat-dev reports Gump can't build, but since they
haven't given us details so not much we can do about it.
Fails to even build on Win32.
-1 for beta on 2.1.3.
Onward to 14 ++1 to Sander's efforts to roll out 2.1.4 ...
let's get it right (at least, let's have something that builds,
irrespective of it has the features folks want.)
I've chided tomcat-dev to bother to report to us what their Gump
results are. Would go a long ways to solving a problem we didn't
know exists.
Bill
At 08:51 PM 3/7/2005, Sander Striker wrote:
>Jim Jagielski wrote:
>>I vote +1 for a beta.
>
>Ditto.
>
>Sander
>
Re: [VOTE] 2.1.3 as beta
Posted by Sander Striker <st...@apache.org>.
Jim Jagielski wrote:
> I vote +1 for a beta.
Ditto.
Sander
Re: [VOTE] 2.1.3 as beta
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 7, 2005, at 1:19 AM, William A. Rowe, Jr. wrote:
> At 07:22 AM 3/6/2005, Sander Striker wrote:
>> I assume we are in agreement that the current AAA discussion shouldn't
>> hold up moving to 2.2 either.
>
> Absolutely it does. Either 2.1-dev has made implementing this
> worse (my essentially workable proposal for 2.0 would no longer
> work at all, with no workaround) or 2.1-dev has made implementing
> such a feature possible, even trivial, even if it's not part of
> the httpd-2.2 core. Suggesting we push out 2.2 'as is, whatever'
> would be like having shoved out either Ryan's or Greg's original
> filter stack without the group coming to concensus (and best of
> breed solution.)
>
Bill's point, and it's valid, is whether or not the AAA framework
is robust enough that we can "push" 2.2 with a good warm
and fuzzy feeling that any "fixes or improvements" to it won't
cause an API break (Justin does allude to this). Sure, API
breaks can happen within and between Betas, but they should
be very rare (IMO). I also don't see anything in the
discussion currently which would lead me to believe that
the API we have isn't adequate (at least) to do what
we need done.
I vote +1 for a beta.
Re: [VOTE] 2.1.3 as beta
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Mar 07, 2005 at 12:19:45AM -0600, William A. Rowe, Jr. wrote:
> At 07:22 AM 3/6/2005, Sander Striker wrote:
> >I assume we are in agreement that the current AAA discussion shouldn't
> >hold up moving to 2.2 either.
>
> Absolutely it does. Either 2.1-dev has made implementing this
> worse (my essentially workable proposal for 2.0 would no longer
> work at all, with no workaround) or 2.1-dev has made implementing
> such a feature possible, even trivial, even if it's not part of
> the httpd-2.2 core. Suggesting we push out 2.2 'as is, whatever'
> would be like having shoved out either Ryan's or Greg's original
> filter stack without the group coming to concensus (and best of
> breed solution.)
I believe that analogy is completely without merit.
The filter stack is at the heart of httpd's module design. The AAA
functionality that is being discussed is relatively minor and the specific
issue that has been raised has *never* been present before.
When we come to agreement upon a solution for the AAA issue, then, per my
proposal previously sent to dev@httpd, with 3 +1s we can change the API in the
beta series. Yet, I don't believe *any* proposal or suggestion in the AAA
threads so far makes changes the API in any way - it only adds functionality.
Currently, we are being held up by gunpoint because you want to wait for a
perfect beta. By definition, a perfect release should be a GA not a beta!
So, I reiterate that this one minor issue should not be holding us up from a
beta. This AAA code has been in the tree for *years* and you are just now
complaining about a feature that has never existed? I kindly ask that you
please stop getting in the way of forward progress. -- justin
Re: [VOTE] 2.1.3 as beta
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 07:22 AM 3/6/2005, Sander Striker wrote:
>I assume we are in agreement that the current AAA discussion shouldn't
>hold up moving to 2.2 either.
Absolutely it does. Either 2.1-dev has made implementing this
worse (my essentially workable proposal for 2.0 would no longer
work at all, with no workaround) or 2.1-dev has made implementing
such a feature possible, even trivial, even if it's not part of
the httpd-2.2 core. Suggesting we push out 2.2 'as is, whatever'
would be like having shoved out either Ryan's or Greg's original
filter stack without the group coming to concensus (and best of
breed solution.)
I'm not saying we need to have this module. I'm asking if our
new auth framework is worse or better than yesterday's for folks
to build upon it.
I'm sensing from comments that we've created a more complex
structure which is harder to work with, but might not quite solve
real world problems. If that's true (I'm +/-0 on deciding until
I work this into 2.1-dev auth) then I'm one -1 on 2.2.0.
The point to 2.2 is we are doing things that 2.0 couldn't. Either
we have added such things well, or poorly. Only alphas in the
hands of module authors tell us the answer to this. [For that
matter, something somewhere needs to attract our module community
to investigate, I don't think we successfully have engaged them.
Not even some high level "what's changed" exists today other than
good old CHANGES.txt.]
That said - -nothing- should ever hold up 2.1.x alpha anytime
someone has the energy to run with the ball!