RE: Auth: Start the httpd-2.1 branch finally?
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] Sent: 14 October 2002 01:05 At 05:33 PM 10/13/2002, Justin Erenkrantz wrote: --On Sunday, October 13, 2002 5:15 PM -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: You haven't read a single email on this thread. The ENTIRE POINT of this thread is that we have a radical change. Auth. Two Bills and who knows whom all else may concur that we can't reasonably force this change into 2.0 for docs and upgrade reasons. Ten binding votes were cast for this change with the understanding that it might break backwards compatibility. Only one binding vote was cast for the aaa rewrite being in 2.1. First, anyone can vote. Only committers have vetos. 2.0: rbb, brianp, dreid, gstein, jim, rederpj, striker, trawick, ianh, gs, bnicholes 2.1: dpejesh, chris, aaron, hb Note that neither Bill voted, apparently that would be six votes for 2.1. But you are ignoring that striker has already implicitly voted against 2.0 by releasing 2.0.42 sans auth changes. Errr, if I in my role as RM decide that a change doesn't go in I usually have a good reason for that. This, however, doesn't translate to an implicit vote against the change in 2.0. I didn't include the auth changes because I tagged STRIKER_2_0_41_PRE1 _before_ the auth changes were committed. In the release cycle I didn't decide to include the shiny new code because: - the docs weren't complete; - the code was so new that I wasn't comfortable with it yet. FYI, it was possible that the tree was left in a 'broken' state for a while due to the aaa changes, and that's why we decided to move forward and release 2.0.41 (which turned into 2.0.42). Simply not to have our users wait longer on the bugfixes that were already present. My vote to keep the aaa changes in 2.0 still stands. And I released 2.0.43 sans auth changes. I said, I'm not vetoing without three strong -1's on this code. I'm not certain Bill's concerns are addressed. I'm not certain Aaron's are addressed. After I get strong -1's, I'll personally veto. Then we can resume the 2.1 branch discussion as a separate point. Will you consider the concerns of others regarding branching aswell? I've seen a lot more people voicing concerns in that area than in keeping the aaa changes in 2.0. Sander
Re: Auth: Start the httpd-2.1 branch finally?
Jim Jagielski wrote: William A. Rowe, Jr. wrote: Branch 2.1 now? Only if we want to release the auth changes with all of the upgrade issues of deprecating several released module. It doesn't matter that only the names have changed, this is called deprecating a module, and it shouldn't happen within a GA release cycle on the same minor version. But we've done it before... IIRC the referer logging module for example. i wasn't allowed to deprecate mod_log_referer and mod_log_agent until mod_log_config was able to provide equivalent functionality. what bothers me about this whole mess is that i don't understand how other projects manage to have two active streams, stable and development. i haven't participated in any that did, so how they accomplish it without all the backward/forward porting pain we always have mystifies me. we really need to come up with a set of guidelines and methodology for this stuff, since we keep repeating the same discussion again and again and again. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp!
Re: Auth: Start the httpd-2.1 branch finally?
* Justin Erenkrantz wrote:
I believe mod_authz_host is a much better name for mod_access. It
indicates that this module is only dealing with authorization based
on the remote host components. mod_access can mean lots of things,
but the fact that it was solely restricted to hostnames wasn't
obvious to me from the original module name. -- justin
hmm. It can also deny/allow from all, env or subnet. So I guess,
mod_access is not really a bad name for the module, for (not serious)
example:
BrowserMatch MSIE dont-like-your-browser
Deny from env=dont-like-your-browser
;-)
nd
--
my japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join #
[ $japh =~ /{(.)}/] - [0] = map $_ - () #André Malo #
= japh;# http://www.perlig.de/ #
Re: Auth: Start the httpd-2.1 branch finally?
André Malo wrote: hmm. It can also deny/allow from all, env or subnet. So I guess, mod_access is not really a bad name for the module, for (not serious) example: BrowserMatch MSIE dont-like-your-browser Deny from env=dont-like-your-browser if it had to be renamed, it might have been better to name it according to its function -- namely, providing strong authentication (that which doesn't consult the user for credentials, and returns 403 on failure rather than 401). so mod_auth_strong, maybe. :-) -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp!
Re: Auth: Start the httpd-2.1 branch finally?
At 05:30 AM 10/14/2002, Rodent of Unusual Size wrote: Jim Jagielski wrote: William A. Rowe, Jr. wrote: Branch 2.1 now? Only if we want to release the auth changes with all of the upgrade issues of deprecating several released module. It doesn't matter that only the names have changed, this is called deprecating a module, and it shouldn't happen within a GA release cycle on the same minor version. But we've done it before... IIRC the referer logging module for example. i wasn't allowed to deprecate mod_log_referer and mod_log_agent until mod_log_config was able to provide equivalent functionality. I think everyone believes that the auth reorganization now handles all of the original functionality of the older auth generation. So that shouldn't be a concern. Old Timers, what was the impact of deprecating mod_log_referer and mod_log_agent mid-release within the 1.3 stream? How would you classify the hardship on the group (in terms of support) and on the upgraders? (Within the same version, as I am not concerned with the usual hassles of a 1.2-1.3 sort of upgrade.) what bothers me about this whole mess is that i don't understand how other projects manage to have two active streams, stable and development. i haven't participated in any that did, so how they accomplish it without all the backward/forward porting pain we always have mystifies me. we really need to come up with a set of guidelines and methodology for this stuff, since we keep repeating the same discussion again and again and again. For example, Jakarta (an ASF project), which at any given time has work progressing on the 'next generation' (now Tomcat 5.0), the current generation (now Tomcat 4.1?) And occasionally patching the older generations (such as Tomcat 4.0 and 3.2 final releases.) Bill
Re: Auth: Start the httpd-2.1 branch finally?
At 6:30 AM -0400 10/14/02, Rodent of Unusual Size wrote: Jim Jagielski wrote: William A. Rowe, Jr. wrote: Branch 2.1 now? Only if we want to release the auth changes with all of the upgrade issues of deprecating several released module. It doesn't matter that only the names have changed, this is called deprecating a module, and it shouldn't happen within a GA release cycle on the same minor version. But we've done it before... IIRC the referer logging module for example. i wasn't allowed to deprecate mod_log_referer and mod_log_agent until mod_log_config was able to provide equivalent functionality. A-hem. The point (for those who were paying attention) was that it did not require a minor bump. IIRC this happened like between 1.3.4 and 1.3.5 or something. It did *not* make us bump from 1.3 to 1.4 (or 1.2 to 1.3). -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Auth: Start the httpd-2.1 branch finally?
Justin Erenkrantz wrote: --On Sunday, October 13, 2002 9:36 PM -0400 Joshua Slive [EMAIL PROTECTED] wrote: One more note: I'd like to see the rename of mod_access reversed. That just seems like a gratuitous change that hurts users and doesn't really help developers. Could you please explain why breaking out the authorization (authz) components in a similar fashion to authentication (authn) is a gratuitous change? I believe mod_authz_host is a much better name for mod_access. It indicates that this module is only dealing with authorization based on the remote host components. mod_access can mean lots of things, but the fact that it was solely restricted to hostnames wasn't obvious to me from the original module name. -- justin Sure, mod_authz_host is a slightly better name. But it does not justify the confusion of renaming the module. I'm looking at benefit/cost here, and I see only a small benefit with a significant cost. The other auth changes also have a significant cost, but they have a greater benefit. Joshua.
RE: Auth: Start the httpd-2.1 branch finally?
Justin Erenkrantz wrote: --On Sunday, October 13, 2002 9:36 PM -0400 Joshua Slive [EMAIL PROTECTED] wrote: One more note: I'd like to see the rename of mod_access reversed. That just seems like a gratuitous change that hurts users and doesn't really help developers. Could you please explain why breaking out the authorization (authz) components in a similar fashion to authentication (authn) is a gratuitous change? I believe mod_authz_host is a much better name for mod_access. It indicates that this module is only dealing with authorization based on the remote host components. mod_access can mean lots of things, but the fact that it was solely restricted to hostnames wasn't obvious to me from the original module name. -- justin Sure, mod_authz_host is a slightly better name. But it does not justify the confusion of renaming the module. I agree. Bill
RE: Auth: Start the httpd-2.1 branch finally?
At 04:05 PM 10/12/2002, Sander Striker wrote:
From: Aaron Bannert [mailto:[EMAIL PROTECTED]]
Sent: 12 October 2002 22:18
On Sat, Oct 12, 2002 at 10:37:07AM -0700, Justin Erenkrantz wrote:
I don't have a strong opinion about the authn redesign,
but I do have one change in mind that would fit well in
2.1: async write support. And async read support, but
that may take a lot longer.
My belief is that you should design and code up the async support and
then we can deliberate about where it should go.
That seems like a one-way street to me. How come it's ok to work on the
auth changes in 2.0 but it's not ok for others?
The auth changes were complete before they were applied in the sense that
they didn't leave the tree in a broken state.
But this is exactly my complaint with auth. It has STILL left the docs,
and therefore our users in a broken state. We've rolled two releases
without what is otherwise good code, because of the impact on users.
In fact, we agreed that the project (we were talking about code) could
and should be broken a few weeks, maybe a month, for major changes.
It's getting on two months and still there are next to no docs for this
change. So it's totally unreleaseable.
EVEN if the docs are done, how can they help both our 2.0-pre-auth
and 2.0-post-auth users at the same time??? I'm objecting from a
DOCS point of view, folks still lookup 1.3 docs on our website!
And from the CONFIG point of view ... folks need their hands held
through this upgrade. Who has it in their plans to answer all the
bugzilla reports and redundant questions on the users@httpd lists?
It's ok to work on ANYTHING. We are all agreeing to this. The question
Ryan raised is, does it belong in 2.0 or 2.1. As Jim asked, are you looking
for a playground for good ideas or do you have solid problems to solve?
I'm suggesting that 2.1 should exist today. It took Ryan (and others) over
two years to create a GA tree. If we continue with design-by-committee,
it's time to begin development.
These changes shouldn't be held up by the fact that
we don't have a 2.1 yet.
I agree, as a matter of fact, I don't think any changes should be held
up for any reason whatsoever.
We all agree. If we need 2.1 let's create it already. Nobody ever said that
1.1 was 'complete' before 1.2 development began. Nobody has ever implied
that the final subversion of any revision is IT. It's never DONE. Let's
take big changes and call them version bumps when we should. And get
that to release state and out the door as quickly as possible.
How's this for simple? Create httpd-2.1 and back out Justin's changes
from httpd-2.0 so we don't break our users. If someone wants to change
more APIs in httpd-2.1, let them do so. When it's ready, we release it and
start supporting it just as httpd-2.0. We effectively drop httpd-2.0 at the
release of httpd-2.1 except for security patches, and anything anybody
really wants to commit. But the focus is on the last GA code, just as
today. {Sure little bugs get fixed occasionally in apache-1.3. Nothing's
wrong with that, or with continuing that tradition in httpd-2.0.}
What's defined as 'ready' for httpd-2.1? That it works, that it is a GA
quality release. If we can fix other foobars we made while designing 2.0,
that would be terrific. Bugs fixed in the httpd-2.0 tree can be committed
to the httpd-2.1 tree. But let's set our sights on an early release, some
time this winter if not by year end.
Perhaps what scares some developers is the HUGE time between the
idea of 2.0 and it's eventual GA release. There is no reason we should
get bogged down agian. Sure, there is a quick alpha-beta-GA cycle,
but we have that down to a science.
Bill
Re: Auth: Start the httpd-2.1 branch finally?
On Sun, Oct 13, 2002 at 06:39:28AM -0400, Jeff Stuart wrote: ... And now you want to create an Apache 2.1! Oy! Give the third party developers a LITTLE bit of time to catch up. :) The presence of an httpd 2.1 would have *ZERO* effect on them supporting a 2.0 release. If anything, it would help in that we would no longer be changing 2.0 as much. So... I'm not sure that I agree with your statement above... Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Auth: Start the httpd-2.1 branch finally?
On Sat, Oct 12, 2002 at 05:11:29PM -0400, Jim Jagielski wrote: This is going to sound like a grumpy old man talking, but it's sounding more and more like that 2.0 tree is considered, by many of the developers, little more than a playground to hack around in. There seems very little regard for end users or developers (API changes with every release... yeah, so what.). Are people hacking 2.0 (or 2.1) because it's fun to do and a neat project, or is there a desire that *people actually use the code*? I'm certainly not saying that we ship broken or stupid code simply to get it out, but certainly people should be aware that, when all is said and done, isn't the whole idea of ASF projects is that people are encouraged to use them? Yeah, we should allow the API to grow and mature, but having it constantly change means, at a very core level, we have no idea what it should be doing or how it should be doing it. [...] Combine this with what Brian Pane wrote in an earlier message: There's one thing about this proposal that I really like: It creates a schedule goal for 2.1. In the past, I've been opposed to jumping to 2.1 because it was so vaguely defined that one couldn't be sure if delaying a feature to 2.1 meant it will be out next quarter or it will be out in a few years. If we can build consensus around a 2.1 with a limited feature set and schedule, them I'm much more interested... Here's how I feel: To avoid splitting developer resources (and patience) between trees, the 2.0 tree should be feature-complete before starting the 2.1 tree. (And AFAIK, no one has defined feature-complete for 2.0.) Once the 2.1 tree is started, primary development (head) should be in that tree, with features backported to 2.0/1.3 as appropriate. While I'm not a fan of compatilibility breakage between _every_ minor release; occasional breakage is OK when discussed and voted upon, as happened in the case of the auth changes. Since I haven't heard anyone say 2.0 is *DONE*, in the sense of baked, decorated, and served beats metaphor into new starter dough, why start 2.1? As Justin Erenkrantz said: Lead with the code - once the code is written or we have a plan of attack, we can find a home for it. In other words, once the code is there, then it can be determined if the change is radical enough to warrant 2.1. Does this conversation sound familiar or is it just me? :-) -Glenn
Re: Auth: Start the httpd-2.1 branch finally?
On Sat, 12 Oct 2002, Glenn wrote:
Glenn, thanks I had deleted Jim's message and I was re-creating it. You
made it so I didn't have to. :-)
On Sat, Oct 12, 2002 at 05:11:29PM -0400, Jim Jagielski wrote:
This is going to sound like a grumpy old man talking, but it's sounding
more and more like that 2.0 tree is considered, by many of the
developers, little more than a playground to hack around in. There
seems very little regard for end users or developers (API changes
with every release... yeah, so what.). Are people hacking 2.0
(or 2.1) because it's fun to do and a neat project, or is there
a desire that *people actually use the code*?
I'm certainly not saying that we ship broken or stupid code simply
to get it out, but certainly people should be aware that, when all
is said and done, isn't the whole idea of ASF projects is that
people are encouraged to use them? Yeah, we should allow the API
to grow and mature, but having it constantly change means, at
a very core level, we have no idea what it should be doing or
how it should be doing it. [...]
I think there is a much easier way to satisfy everybody and stay in the
2.0 tree. The problem right now, is that the MMN isn't granular
enough. All we know, is that we broke binary compatibility. But, we
don't know where it was broken, which means that all modules must be
re-compiled. But, let's take the auth changes as an example. We had to
bump the MMN with these changes, because of what was done. But, the only
modules that were affected, were auth modules. That means that anybody
who has a filter oesn't need to re-compile.
If we modularize the MMN, and provide a way for module authors to query
the MMN at a granular level, most of the MMN bumps become much more
trivial. Let me explain what I mean.
#define MAJOR_MMN 0
#define AUTH_MMN 000
#deifne FILTER_MMN 000
...
#define MMN MAJOR_MMN,AUTH_MMN,FILTER_MMN
int check_auth_api(int module_number)
{
if GET_AUTH_MMN(module_number) AUTH_MMN) {
return false; /* May want to just exit with an error here */
}
return true;
}
Now, and auth module just needs to call check_auth_api() in
register_hooks. If it returns false, the module needs to exit, or things
will fail. If it returns true, then all is good.
If the module doesn't call any of the individual check_*_aupi() functions,
then the best we can do is to check the whole thing the way we do now.
The advantage to this, is that it allows us to bump the MMN when we need
to, but that bump is less likely to affect as many people.
I see how to implement the whole thing if this will satisfy people.
Ryan
RE: Auth: Start the httpd-2.1 branch finally?
On Sat, Oct 12, 2002 at 10:37:07AM -0700, Justin Erenkrantz wrote: I don't have a strong opinion about the authn redesign, but I do have one change in mind that would fit well in 2.1: async write support. And async read support, but that may take a lot longer. My belief is that you should design and code up the async support and then we can deliberate about where it should go. That seems like a one-way street to me. How come it's ok to work on the auth changes in 2.0 but it's not ok for others? I didn't make enough noise about this the first time around. I would like to see the auth changes taken out of 2.0 and moved into 2.1. We need to stablize the API in 2.0 for a reasonable amount of time to encourage module authors to begin porting their modules to 2.0. Bill
RE: Auth: Start the httpd-2.1 branch finally?
Speaking as an end user, my problem is this:
Module development. PHP STILL does not officially support Apache 2. It
is still marked as experimental. Mod_perl still doesn't support Apache
2.
For me, these are the 2 third party modules I use. Yes, the onus DOES
rest on the developers of these modules to port over. However, if the
API keeps changing underneath their feet... I can understand WHY it's
taking them as long as it has to officially support Apache 2.0.
And now you want to create an Apache 2.1! Oy! Give the third party
developers a LITTLE bit of time to catch up. :)
On Sat, 2002-10-12 at 20:17, William A. Rowe, Jr. wrote:
How's this for simple? Create httpd-2.1 and back out Justin's changes
from httpd-2.0 so we don't break our users. If someone wants to change
more APIs in httpd-2.1, let them do so. When it's ready, we release it and
start supporting it just as httpd-2.0. We effectively drop httpd-2.0 at the
release of httpd-2.1 except for security patches, and anything anybody
really wants to commit. But the focus is on the last GA code, just as
today. {Sure little bugs get fixed occasionally in apache-1.3. Nothing's
wrong with that, or with continuing that tradition in httpd-2.0.}
What's defined as 'ready' for httpd-2.1? That it works, that it is a GA
quality release. If we can fix other foobars we made while designing 2.0,
that would be terrific. Bugs fixed in the httpd-2.0 tree can be committed
to the httpd-2.1 tree. But let's set our sights on an early release, some
time this winter if not by year end.
Perhaps what scares some developers is the HUGE time between the
idea of 2.0 and it's eventual GA release. There is no reason we should
get bogged down agian. Sure, there is a quick alpha-beta-GA cycle,
but we have that down to a science.
Bill
--
Jeff Stuart [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: Auth: Start the httpd-2.1 branch finally?
On Sat, Oct 12, 2002 at 06:18:41PM -0400, [EMAIL PROTECTED] wrote: ... I think there is a much easier way to satisfy everybody and stay in the 2.0 tree. The problem right now, is that the MMN isn't granular enough. All we know, is that we broke binary compatibility. But, we don't know where it was broken, which means that all modules must be re-compiled. But, let's take the auth changes as an example. We had to bump the MMN with these changes, because of what was done. But, the only modules that were affected, were auth modules. That means that anybody Woah! Totally not true. The auth changes DID NOT affect MMN. And they DID NOT affect other auth modules. All the focus around this stuff is a sensitive issue. Let's not make it worse with misinformation. I know it wasn't intentional, but let's not let it spread. The auth change *added* stuff. It absolutely did not change any APIs, so there was no need for an MMN bump. That said, there probably should have been a minor bump so that code can test whether an API is present. But minor bumps are totally righteous. No problem with those. ... If we modularize the MMN, and provide a way for module authors to query the MMN at a granular level, most of the MMN bumps become much more trivial. Let me explain what I mean. +1 on the concept. Along these lines, I've wanted to go into the new provider stuff that Justin added and add a provider-version number. That would allow a person to register a particular version of a provider. This is especially important because I want to make big changes to the mod_dav API, but (today) that would imply an MMN bump. If I can introduce a provider API version, then changes to the mod_dav interface would not kill the whole server -- just DAV providers. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Auth: Start the httpd-2.1 branch finally?
[EMAIL PROTECTED] wrote: In all of these cases, there was a developer or three, who created a CVS tree either in their home directories, or in the main CVS area. They made the major changes that they wanted to see made, and then they announced the changes to the list, and invited people to help them make the projects better. Except for the fact that in all the above cases, the branch being deviated from was a solid, robust and reliable codebase. It was *time* to start a new branch, knowing that the current codebase was, at a very deep level, very robust and baked. Is 2.0? *That* is my only concern regarding a 2.1 branch. It leaves 2.0 in a not-quite-there state. It's the idea that 2.0 is dropped so work can progress on 2.1. PS: I don't see this as another Shambhala situation, by the way. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Auth: Start the httpd-2.1 branch finally?
On Sat, Oct 12, 2002 at 11:23:23PM -0400, Bill Stoddard wrote: On Sat, Oct 12, 2002 at 10:37:07AM -0700, Justin Erenkrantz wrote: I don't have a strong opinion about the authn redesign, but I do have one change in mind that would fit well in 2.1: async write support. And async read support, but that may take a lot longer. My belief is that you should design and code up the async support and then we can deliberate about where it should go. That seems like a one-way street to me. How come it's ok to work on the auth changes in 2.0 but it's not ok for others? I didn't make enough noise about this the first time around. I would like to see the auth changes taken out of 2.0 and moved into 2.1. We need to stablize the API in 2.0 for a reasonable amount of time to encourage module authors to begin porting their modules to 2.0. The API *is* stable. The auth changes did nothing to the API except to expand it a bit for *new* auth systems. Existing auth modules are unaffected. There were some directive changes, and certainly some different modules to load, but nothing in the API department. Moreover, I think we can deal with the directives and create some kind of backwards-compat stuff. It is just that I'm not entirely sure what got dropped and added yet. The modules are a bit tougher. We could potentially fix it with hacks to the module loading stuff to key off the old names and load the new stuff, but that just feels fugly... Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Auth: Start the httpd-2.1 branch finally?
On Sat, 12 Oct 2002, Jim Jagielski wrote: [EMAIL PROTECTED] wrote: In all of these cases, there was a developer or three, who created a CVS tree either in their home directories, or in the main CVS area. They made the major changes that they wanted to see made, and then they announced the changes to the list, and invited people to help them make the projects better. Except for the fact that in all the above cases, the branch being deviated from was a solid, robust and reliable codebase. It was *time* to start a new branch, knowing that the current codebase was, at a very deep level, very robust and baked. Is 2.0? *That* is my only concern regarding a 2.1 branch. It leaves 2.0 in a not-quite-there state. It's the idea that 2.0 is dropped so work can progress on 2.1. PS: I don't see this as another Shambhala situation, by the way. I am less concerned about *if* we should do a 2.1 branch, and more concerned with *how* it is being done. In the message above, I don't think you are advocating a 2.1 branch. It sounds like you believe that we should take the time to finish 2.0 before moving on. Am I right in interpreting it that way? Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
--On Friday, October 11, 2002 10:59 PM -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I'm calling for a consensus opinion that the mod_auth changes are simply too radical to introduce into a current version. We keep treating the GA tree as a development branch. Many newcomers (with less than a couple of years here in httpd land) and a very few old timers persist in doing so. We had a vote before the changes were checked in. I don't know what else you'd like to have done. It was the stated consensus of the group that these changes go into 2.0 not a 2.1 - knowing full well that it could break directive compatibility. So, I think the notion that some rule was violated is absurd - I believe everything was done in the mystical 'Apache way.' The one thing that I dislike about a 2.1 is that we've stated that we can't force any developer to go to the new version. Other committers have stated that they won't develop or forward-port fixes to 2.1. And, some developers might not back-port fixes from a 2.1 to 2.0. That's not going to be helpful to our users. My hope is that when we go to a 2.1, all developers believe it is time and 2.0 should be closed. Right now, I don't believe that is the case. -- justin
Re: Auth: Start the httpd-2.1 branch finally?
--On Friday, October 11, 2002 10:00 PM -0700 Brian Pane [EMAIL PROTECTED] wrote: I don't have a strong opinion about the authn redesign, but I do have one change in mind that would fit well in 2.1: async write support. And async read support, but that may take a lot longer. My belief is that you should design and code up the async support and then we can deliberate about where it should go. These changes shouldn't be held up by the fact that we don't have a 2.1 yet. Lead with the code - once the code is written or we have a plan of attack, we can find a home for it. IMHO, that's the only way things happen around here. -- justin
RE: Auth: Start the httpd-2.1 branch finally?
From: Aaron Bannert [mailto:[EMAIL PROTECTED]] Sent: 12 October 2002 22:18 On Sat, Oct 12, 2002 at 10:37:07AM -0700, Justin Erenkrantz wrote: I don't have a strong opinion about the authn redesign, but I do have one change in mind that would fit well in 2.1: async write support. And async read support, but that may take a lot longer. My belief is that you should design and code up the async support and then we can deliberate about where it should go. That seems like a one-way street to me. How come it's ok to work on the auth changes in 2.0 but it's not ok for others? The auth changes were complete before they were applied in the sense that they didn't leave the tree in a broken state. These changes shouldn't be held up by the fact that we don't have a 2.1 yet. I agree, as a matter of fact, I don't think any changes should be held up for any reason whatsoever. Sander
Re: Auth: Start the httpd-2.1 branch finally?
This is going to sound like a grumpy old man talking, but it's sounding more and more like that 2.0 tree is considered, by many of the developers, little more than a playground to hack around in. There seems very little regard for end users or developers (API changes with every release... yeah, so what.). Are people hacking 2.0 (or 2.1) because it's fun to do and a neat project, or is there a desire that *people actually use the code*? I'm certainly not saying that we ship broken or stupid code simply to get it out, but certainly people should be aware that, when all is said and done, isn't the whole idea of ASF projects is that people are encouraged to use them? Yeah, we should allow the API to grow and mature, but having it constantly change means, at a very core level, we have no idea what it should be doing or how it should be doing it. I know some of this is not germane to the current question and issue, but some of it is. Recall that when all this started, we were users who developed because we were users; we weren't developers who simply used what we developed. It was real, not an programming exercise. Anyway, I've most likely upset a few people, and I apologize in advance. Just take these words from someone who *still* wants Apache to achieve world domination :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Auth: Start the httpd-2.1 branch finally?
Anyway, I've most likely upset a few people, and I apologize in advance. Just take these words from someone who *still* wants Apache to achieve world domination :) As a user I'll try to help achiving this goal ;) About the specific issue: I (again as a user) like the idea of at least putting the old auth modules in the coming 2.0 releases, so that compatibility between the minor releases - which certainly is important for adoption - is not broken and a smoother transistion to the newer - and probably better - auth module design gets possible. On the other hand I am just a little user so I don't really know what disadvantages this may have (except that people stay with the old auth modules forever;) just my 2cents :-) ..nice weekend cheers johannes -- A woman without a man is like a fish without a bicycle. - http://jgcl.at/ko/ - new photos from summer camp 2002 in Moosen/Tirol
Re: Auth: Start the httpd-2.1 branch finally?
I finally figured out why a 2.1 branch bothers me so much. It isn't being done the way it should be done. When apache-nspr was created, it wasn't because there was a big discussion on-list and Dean decided to go do the work. When apache-apr was created, it wasn't because Bill, Manoj, and I started a big discussion and then did the work. When apache-2.0 was created, it wasn't becasue Dean explained what he wanted to do to apache-apr and then did the work. When httpd-2.0 was created, Roy didn't explain what he was going to do, and then go do the work. In all of these cases, there was a developer or three, who created a CVS tree either in their home directories, or in the main CVS area. They made the major changes that they wanted to see made, and then they announced the changes to the list, and invited people to help them make the projects better. One of three things happened with these trees. Either they were picked up as the new development tree and the old tree was lost. Or, they were completely ignored. Or, they were tried and rejected for specific reasons. With the fabled 2.1 branch, people want to have a discussion about what is going to go into it, then they want to fork, and then they want to start writing code. That is a completely backwards approach. If you have a major change that you want to make to 2.0, make the change, either in a sandbox, or in a copy of the current tree. Then, invite people to look at what you did. Once we see how big the change is, we can decided if 1) We like the change to you made, and 2) if it is big enough to warrant a bump to 2.1. There is no push to branch 2.1, becasue there is no code that warrants a branch. Personally, if you are going to write cod, I suggest just creating a CVS repository in your home directory, and allowing people to collaborate there. If the code is accepted, it is easy to move it into the main CVS area. In fact, of all of the examples above, I don't thik anybody started working in the main CVS area. I know Dean didn't with either apache-nspr or apache-2.0. I think Roy had a basically working copy before httpd-2.0 was created, and Billo and I worked without CVS until Manoj started helping us. Bottom-line: Talking about a branch before there is any code is completely bogus. None of us know what is going to be in 2.1. I know I have some ideas for how to do the filesystem abstraction that I want to play around with. But I also know that a bunch of other people have ideas too. Which one will be the foundation for the work? I don't know, and I can't until we see some actual code. Why should one person be allowed to put their code in the httpd-2.1 branch? They shouldn't. I will personally be doing some pwork in /home/rbb/cvs either on www.apache.org or www.rkbloom.net in the next few weeks. Once I have a working prototype, I will open it up to people to look at and play with. Only then can we decide if it belongs in 2.1 or 2.0. As for the Auth patches, BTW, the code was created first, and then it was decided to put it in 2.0. That was the way it should be done. However, Justin, it would be really cool if you could create a simple Perl script that takes an old config and updates it to a new one. It may just be the LoadModule lines, but automating that work would be really nice for our users. That idea was thrown out in a conversation I had with Will. I think it was his idea, but I honestly can't remember. Ryan On Sat, 12 Oct 2002, Justin Erenkrantz wrote: --On Friday, October 11, 2002 10:59 PM -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I'm calling for a consensus opinion that the mod_auth changes are simply too radical to introduce into a current version. We keep treating the GA tree as a development branch. Many newcomers (with less than a couple of years here in httpd land) and a very few old timers persist in doing so. We had a vote before the changes were checked in. I don't know what else you'd like to have done. It was the stated consensus of the group that these changes go into 2.0 not a 2.1 - knowing full well that it could break directive compatibility. So, I think the notion that some rule was violated is absurd - I believe everything was done in the mystical 'Apache way.' The one thing that I dislike about a 2.1 is that we've stated that we can't force any developer to go to the new version. Other committers have stated that they won't develop or forward-port fixes to 2.1. And, some developers might not back-port fixes from a 2.1 to 2.0. That's not going to be helpful to our users. My hope is that when we go to a 2.1, all developers believe it is time and 2.0 should be closed. Right now, I don't believe that is the case. -- justin -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610
Re: Auth: Start the httpd-2.1 branch finally?
On Sat, 12 Oct 2002, Justin Erenkrantz wrote: --On Friday, October 11, 2002 10:00 PM -0700 Brian Pane [EMAIL PROTECTED] wrote: I don't have a strong opinion about the authn redesign, but I do have one change in mind that would fit well in 2.1: async write support. And async read support, but that may take a lot longer. My belief is that you should design and code up the async support and then we can deliberate about where it should go. These changes shouldn't be held up by the fact that we don't have a 2.1 yet. Lead with the code - once the code is written or we have a plan of attack, we can find a home for it. IMHO, that's the only way things happen around here. -- justin Damn Justin, I just spent three pages saying this exactly. Run for the hills everybody, Justin and I agree. There is bound to be a flood or some event of biblical proportions somewhere. :-) Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
[EMAIL PROTECTED] wrote: In the message above, I don't think you are advocating a 2.1 branch. It sounds like you believe that we should take the time to finish 2.0 before moving on. Am I right in interpreting it that way? +++1 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Auth: Start the httpd-2.1 branch finally?
I am so sick of this conversation. 2.0 isn't done yet. It won't be done until it is actually stable, and it isn't currently stable. But, you have worn me down. Create a new fscking tree, populate it and begin working on it. I will be finishing 2.0. And yes, this is very harshly worded. We have had this conversation multiple times, and everytime, the same people want to branch, and the same people want to stabilize the server. If you can't deal with taking the time to stabilize the server, then branch the tree. But, do not even think of saying that the MMN of 2.0 can't change just because you have created a new tree. Ryan
Re: Auth: Start the httpd-2.1 branch finally?
At 11:21 PM 10/11/2002, [EMAIL PROTECTED] wrote: I am so sick of this conversation. 2.0 isn't done yet. It won't be done until it is actually stable, and it isn't currently stable. Fine. That's no reason to deprecate modules mid-stream. Was it a good choice to rename mod_access to mod_auth_host? Well, I suppose it makes much more sense, from our view. But from a common sense administrators view, that's OS Coders fsking around with naming for the sake of changing the names. And it does them no practical good. But, you have worn me down. Create a new fscking tree, populate it and begin working on it. I will be finishing 2.0. My analogy was bad. Let me rephrase. 1.3 is mixed, baked and now cooling down. 2.0 is mixed, still baking and won't cool down for a while. I'm asking that we move Justin's changes to 2.1 and start mixing the danged thing already. And let that not stop anyone from fixing bugs!!! When the right fix is a straightforward change to some borked code, apply it to both trees at once. If the right fix is to redesign the server, axe a module, or whatever, then lets do that in a 2.1 tree. And yes, this is very harshly worded. We have had this conversation multiple times, and everytime, the same people want to branch, and the same people want to stabilize the server. If you can't deal with taking the time to stabilize the server, then branch the tree. But, do not even think of saying that the MMN of 2.0 can't change just because you have created a new tree. Of course the httpd project will always have cross purposes by the coders and other contributors. Everyone here has itches to scratch. That's GOOD! If we didn't, this project would be dead long ago. I'm asking for Justin''s revamp to come out of 2.0. I'm suggesting it go immediately into a new tree. If that is reasonable to people, please say so. If I'm being unreasonable, please point that out. I'm suggesting that Justin's change doesn't stabilize the tree. You want us all rowing with you in the same direction. That isn't open source development within the Apache framework. That's Joes' Project on sourceforge, or the Linux model. It's not the Apache way. So rather than argue, let's provide the tree for folks to explore their new efforts. Won't be in anyone's way. In fact, it will improve the stability of the GA branch, which is something I believe ALL of us desire. Bill
Re: Auth: Start the httpd-2.1 branch finally?
On Fri, 11 Oct 2002, William A. Rowe, Jr. wrote: At 11:21 PM 10/11/2002, [EMAIL PROTECTED] wrote: I am so sick of this conversation. 2.0 isn't done yet. It won't be done until it is actually stable, and it isn't currently stable. Fine. That's no reason to deprecate modules mid-stream. Was it a good choice to rename mod_access to mod_auth_host? Well, I suppose it makes much more sense, from our view. But from a common sense administrators view, that's OS Coders fsking around with naming for the sake of changing the names. And it does them no practical good. Then put the old modules back in. They still work, they just don't work as well. But, you have worn me down. Create a new fscking tree, populate it and begin working on it. I will be finishing 2.0. My analogy was bad. Let me rephrase. 1.3 is mixed, baked and now cooling down. 2.0 is mixed, still baking and won't cool down for a while. I'm asking that we move Justin's changes to 2.1 and start mixing the danged thing already. And let that not stop anyone from fixing bugs!!! When the right fix is a straightforward change to some borked code, apply it to both trees at once. If the right fix is to redesign the server, axe a module, or whatever, then lets do that in a 2.1 tree. In other words, stop all new development in 2.0. Nope. It's bogus, the server is ready for it. And yes, this is very harshly worded. We have had this conversation multiple times, and everytime, the same people want to branch, and the same people want to stabilize the server. If you can't deal with taking the time to stabilize the server, then branch the tree. But, do not even think of saying that the MMN of 2.0 can't change just because you have created a new tree. Of course the httpd project will always have cross purposes by the coders and other contributors. Everyone here has itches to scratch. That's GOOD! If we didn't, this project would be dead long ago. I'm asking for Justin''s revamp to come out of 2.0. I'm suggesting it go immediately into a new tree. If that is reasonable to people, please say so. If I'm being unreasonable, please point that out. I'm suggesting that Justin's change doesn't stabilize the tree. You want us all rowing with you in the same direction. That isn't open source development within the Apache framework. That's Joes' Project on sourceforge, or the Linux model. It's not the Apache way. I absolutely hate the phrase the Apache way. I hate it for a simple reason. Nobody knows what the hell it is. HAve you noticed yet that people throw it around when they want things to work their way? I haven't asked everybody to do what I say. I personally have a couple of projects that I care about, and I am ignoring the rest of the BS. But I worked too damned hard, as did a lot of other people, to move on to 2.1 just when people are starting to port their modules to 2.0. You are being unreasonable. This was disucsssed, you were a part of the discussion. It was decided to put this stuff into the 2.0 tree. Justin updated the docs, there was some small discussion over how to deal with having docs for both sets of modules. That hasn't been resolved yet. So rather than argue, let's provide the tree for folks to explore their new efforts. Won't be in anyone's way. In fact, it will improve the stability of the GA branch, which is something I believe ALL of us desire. Because it won't have an impact on the 2.0 tree. I and others will continue to improve Apache 2.0 to solve people's problems. All it will do, is confuse users, and make it harder to fix problems. Like I said, feel free to branch, but nobody should even try to state that becasue 2.1 was started 2.0 can't have an MMN bump. 2.0 is in it's infancy as a GA server. There are still a lot of changes that can and should happen to it. That is a part of the product lifecycle. deal with it. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
On Sun, 13 Oct 2002, Greg Stein wrote: On Sat, Oct 12, 2002 at 06:18:41PM -0400, [EMAIL PROTECTED] wrote: ... I think there is a much easier way to satisfy everybody and stay in the 2.0 tree. The problem right now, is that the MMN isn't granular enough. All we know, is that we broke binary compatibility. But, we don't know where it was broken, which means that all modules must be re-compiled. But, let's take the auth changes as an example. We had to bump the MMN with these changes, because of what was done. But, the only modules that were affected, were auth modules. That means that anybody Woah! Totally not true. The auth changes DID NOT affect MMN. And they DID NOT affect other auth modules. All the focus around this stuff is a sensitive issue. Let's not make it worse with misinformation. I know it wasn't intentional, but let's not let it spread. The auth change *added* stuff. It absolutely did not change any APIs, so there was no need for an MMN bump. That said, there probably should have been a minor bump so that code can test whether an API is present. But minor bumps are totally righteous. No problem with those. OK. My bad. I am completely incorrect, and I take the blame for that. Sorry. ... If we modularize the MMN, and provide a way for module authors to query the MMN at a granular level, most of the MMN bumps become much more trivial. Let me explain what I mean. +1 on the concept. Along these lines, I've wanted to go into the new provider stuff that Justin added and add a provider-version number. That would allow a person to register a particular version of a provider. This is especially important because I want to make big changes to the mod_dav API, but (today) that would imply an MMN bump. If I can introduce a provider API version, then changes to the mod_dav interface would not kill the whole server -- just DAV providers. I would prefer one API for the provider/MMN check, so I will try to throw something together this week. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
At 05:59 AM 10/13/2002, Greg Stein wrote:
The API *is* stable. The auth changes did nothing to the API except to
expand it a bit for *new* auth systems. Existing auth modules are
unaffected.
To the extent that they don't choose to use the new hooks, I believe
you are right. Certainly no MMN major bump required. The reorganization
is the only issue, and only from a user perspective, not a coding objection.
There were some directive changes, and certainly some different modules to
load, but nothing in the API department. Moreover, I think we can deal with
the directives and create some kind of backwards-compat stuff. It is just
that I'm not entirely sure what got dropped and added yet. The modules are a
bit tougher. We could potentially fix it with hacks to the module loading
stuff to key off the old names and load the new stuff, but that just feels
fugly...
Exactly my point. Few understand what got added and dropped.
It's a mess from an administrators point of view.
The *code* is good. The reorganization is the hardship. Projects shouldn't
(and most would never) demand that users reorganize their configuration
files on a subversion point bump.
So far, Two Bills beg that we defer the auth reorg to 2.1. If I hear three,
I will consider it appropriate to veto the auth reorganization for 2.0, until
we start 2.1. The technical justification would be unreasonable support
traffic (via bugzilla, user lists, etc) in response to administrators as
they are forced through this update. Technically, a reasonable demand
for a version point bump, but not reasonable within a subversion point bump.
Don't get me wrong, I'm ++1 for this change to Apache 2.1, and want to
help folks develop to the new schema for Apache 2.1. I suggest a 2.1
branch for affected files, for now. This makes it simple, when we officially
begin the 2.1 Effort, to merge all the changes from the main branch
and incorporate all 2.1 changes. Only the folks who commit code to
the 2.1 branch are committed to remerging the changes from HEAD.
Folks not interested in participating yet would not be affected by this
side branch.
I still think it's silly to insist that 2.0 be 'perfect' when we can easily
drop support of 2.0 once 2.1 it is just as ready for the prime time.
The 1.3 tree remains supported simply because it is more portable,
the lack of thread support makes it less complex and therefore
(so far) a bit more robust on Unix, and there is a rich history
of modules which {won't be /or/ are still being} ported.
Other thoughts, suggestions or objections?
Bill
Re: Auth: Start the httpd-2.1 branch finally?
At 11:40 AM 10/13/2002, Jim Jagielski wrote: [EMAIL PROTECTED] wrote: In the message above, I don't think you are advocating a 2.1 branch. It sounds like you believe that we should take the time to finish 2.0 before moving on. Am I right in interpreting it that way? +++1 Then I want to clarify ... you both object to the statement that developers within HTTP should be free to work on what they want. Obviously, you are both stating that we should not introduce 2.1 anytime real soon now. Therefore, you are stating that developers are not free to introduce radical new code at the present moment, and only things that fit within Apache 2.0 [subject to perpetual debate over what exactly what fits within 2.0] are open for community development efforts. Please see my other post about offering a 2.1 working branch within the httpd-2.0 tree, maintained only by the 2.1 contributors, and please offer your opinions of that solution. This would apply to docs as well, since folks interested in documenting the demise of mod_access and introduction of mod_authn/authz_foo modules would be free to proceed, while not interfering with the primary httpd-2.0 docs, and picking up revisions and changes by merging the ongoing activity within the httpd-2.0 tree. Bill
Re: Auth: Start the httpd-2.1 branch finally?
On Sun, Oct 13, 2002 at 06:39:28AM -0400, Jeff Stuart wrote: Speaking as an end user, my problem is this: Module development. PHP STILL does not officially support Apache 2. It is still marked as experimental. Mod_perl still doesn't support Apache 2. For me, these are the 2 third party modules I use. Yes, the onus DOES rest on the developers of these modules to port over. However, if the API keeps changing underneath their feet... I can understand WHY it's taking them as long as it has to officially support Apache 2.0. And now you want to create an Apache 2.1! Oy! Give the third party developers a LITTLE bit of time to catch up. :) As an Apache developer who has also worked on the apache2filter for PHP, I'd like to reassure you that changing APIs have little or no negative effect on our ability to stabilize the PHP module for Apache 2. -aaron
Re: Auth: Start the httpd-2.1 branch finally?
On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote: At 11:40 AM 10/13/2002, Jim Jagielski wrote: [EMAIL PROTECTED] wrote: In the message above, I don't think you are advocating a 2.1 branch. It sounds like you believe that we should take the time to finish 2.0 before moving on. Am I right in interpreting it that way? +++1 Then I want to clarify ... you both object to the statement that developers within HTTP should be free to work on what they want. Obviously, you are both stating that we should not introduce 2.1 anytime real soon now. Therefore, you are stating that developers are not free to introduce radical new code at the present moment, and only things that fit within Apache 2.0 [subject to perpetual debate over what exactly what fits within 2.0] are open for community development efforts. Bill, I'm sorry, but you aren't reading the e-mails that have been sent. You want to branch 2.1 so that people can make radical changes. We are saying feel free to create patches with radical changes. Once people can see the patches, we can decide if they belong in 2.1, 2.0, or if we don't want them in Apache at all. If you want to create the patches in a community, then create a CVS repository in your home directory. Please don't call it httpd-2.1, because you don't get to decide that your efforts are 2.1, that is for the group to decide. We are stating quite clearly, that you are free to branch and show us what you want to do in 2.1. What we aren't willing to do, is create a 2.1 tree where everybody is supposed to do their work. There is a good chance that the first few attempts at a 2.1 tree will fail and won't ever see the light of day. Please finally go back and read the messages where people have explained why they don't want to branch. Also, as for the auth stuff, you seem to have completely ignored that Greg has offered a solution that might create backwards compat for the users with the new auth work. You are so focused on getting a 2.1 branch, that you are ignoring any other solutions to the problem that you have raised. Ryan Please see my other post about offering a 2.1 working branch within the httpd-2.0 tree, maintained only by the 2.1 contributors, and please offer your opinions of that solution. This would apply to docs as well, since folks interested in documenting the demise of mod_access and introduction of mod_authn/authz_foo modules would be free to proceed, while not interfering with the primary httpd-2.0 docs, and picking up revisions and changes by merging the ongoing activity within the httpd-2.0 tree. Bill -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
--On Sunday, October 13, 2002 3:59 AM -0700 Greg Stein [EMAIL PROTECTED] wrote: The API *is* stable. The auth changes did nothing to the API except to expand it a bit for *new* auth systems. Existing auth modules are unaffected. Exactly - we only reorganized our aaa modules. No hooks or APIs were modified. Third-party aaa modules require no changes - in fact, our own experimental auth_ldap hasn't been converted (mainly because it is so many files). There were some directive changes, and certainly some different modules to load, but nothing in the API department. Moreover, I think we can deal with the directives and create some kind of backwards-compat stuff. It is just that I'm not entirely sure what got dropped and added yet. The modules are a bit tougher. We could potentially fix it with hacks to the module loading stuff to key off the old names and load the new stuff, but that just feels fugly... My belief is that the only change is in the *Authoritative directives - we're now more granular as we can selectively control authoritativeness on authn and authz modules. There are also some gotchas on the LoadModule lines, but, like you, I'm not really sure what we can do about that. I think the best thing to do is to document the module renames. And, solutions like adding back mod_access or mod_auth can't work since we do not allow modules to share directives - therefore, there will be confusion internally about which modules should handle the authorization when both are loaded. That's badness. -- justin
Re: Auth: Start the httpd-2.1 branch finally?
At 04:36 PM 10/13/2002, Justin Erenkrantz wrote: --On Sunday, October 13, 2002 3:59 AM -0700 Greg Stein [EMAIL PROTECTED] wrote: There were some directive changes, and certainly some different modules to load, but nothing in the API department. Moreover, I think we can deal with the directives and create some kind of backwards-compat stuff. It is just that I'm not entirely sure what got dropped and added yet. The modules are a bit tougher. We could potentially fix it with hacks to the module loading stuff to key off the old names and load the new stuff, but that just feels fugly... My belief is that the only change is in the *Authoritative directives - we're now more granular as we can selectively control authoritativeness on authn and authz modules. There are also some gotchas on the LoadModule lines, but, like you, I'm not really sure what we can do about that. I think the best thing to do is to document the module renames. I challenge you to do so; document both the old and the new so that http://httpd.apache.org/docs-2.0/ clearly documents both the pre-new-auth and post-new-auth. I'm presuming it can't be done -well-, because it hasn't been done. I grappled with the idea this weekend and surrendered. That's when I revisited my original vote to implement this in 2.1 ... like FirstBill offered, I too should have hollered louder. But no users have been harmed, and the code will go in (to 2.0 or 2.1). The fact that we don't know what to do about it speaks volumes as to how difficult this is, and how ill advised this restructuring is for 2.0. Of course we can announce to the world Hey, we were kidding, 2.0 wasn't GA quality, but now it is, and 2.0.47 is the real GA release. [I'm being tongue in cheek here, I believe along with many developers that 2.0 was as ready for GA as it was ever going to be. We couldn't begin to track down the obscure bits without some adopters telling us exactly what was wrong.] And, solutions like adding back mod_access or mod_auth can't work since we do not allow modules to share directives - therefore, there will be confusion internally about which modules should handle the authorization when both are loaded. That's badness. -- justin Of course not. Either the revamped auth goes it, or it's reverted. I agree it's too difficult to have both. Bill
Re: Auth: Start the httpd-2.1 branch finally?
--On Sunday, October 13, 2002 12:30 PM -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: So far, Two Bills beg that we defer the auth reorg to 2.1. If I hear three, I will consider it appropriate to veto the auth reorganization for 2.0, until we start 2.1. The technical justification would be unreasonable support traffic (via bugzilla, user lists, etc) in response to administrators as they are forced through this update. Technically, a reasonable demand for a version point bump, but not reasonable within a subversion point bump. I hereby challenge your 'technical' reason for a veto. Unlike APR, httpd does not have a documented versioning system. Therefore, I don't believe there is any expectation to break. And, when we conducted the vote, I explicitly mentioned that we might break backwards compatibility - the rest of the group didn't seem to have a problem with that. If someone else says your reason is technically valid, our rules states that the veto stands. Fine, but I want to see someone else agree. I think Greg and myself have tried to clarify FirstBill's misunderstanding of what changed. -- justin
Re: Auth: Start the httpd-2.1 branch finally?
At 1:05 PM -0500 10/13/02, William A. Rowe, Jr. wrote: Then I want to clarify ... you both object to the statement that developers within HTTP should be free to work on what they want. Obviously, you are both stating that we should not introduce 2.1 anytime real soon now. In a nutshell, here are my thoughts: Creating a 2.1 branch will sacrifice 2.0. I really feel that if 2.1 is started, 2.0 will basically stay the exact same way it is right now. And although 2.0 *is* production ready, there is still a lot more that could be done with it, to make it better. Consider what happened with 2.0 and 1.3: When 2.0 started in earnest development on 1.3 was frowned upon. No new features and the like. 2.0 was the cool project to work on, and 1.3 was considered old stuff. This only succeeded because (1) 1.3 was very, very robust. It was solid and had been worked on and tuned enough that it could be somewhat left alone and (2) that some of us decided to make sure that 1.3 was still a living a breathing project, despite some developer inklings that you should really be working on 2.0. 2.0 is not, IMO, at a stage where a 2.1 branch is warranted. There's still a lot that can, and should be done in 2.0. If it means an API change, well, if the need is strong enough, then that's that. My concern about the API was a growing tendency towards being able to justify an API change for anything. People *want* to use 2.0: let's make it easy for them. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Auth: Start the httpd-2.1 branch finally?
--On Sunday, October 13, 2002 4:57 PM -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I challenge you to do so; document both the old and the new so that http://httpd.apache.org/docs-2.0/ clearly documents both the pre-new-auth and post-new-auth. I'm presuming it can't be done -well-, because it hasn't been done. I grappled with the idea this weekend and surrendered. That's when I revisited my original vote to implement this in 2.1 ... like FirstBill offered, I too should have hollered louder. But no users have been harmed, and the code will go in (to 2.0 or 2.1). I'm sorry, but I don't see a need to have the documentation refer to historical (or deprecated) modules. If you have an older version, the docs included in that release tarball are the definitive version. IMHO, the docs on the website should only refer to the currently released version. -- justin
Re: Auth: Start the httpd-2.1 branch finally?
At 03:33 PM 10/13/2002, [EMAIL PROTECTED] wrote: On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote: At 11:40 AM 10/13/2002, Jim Jagielski wrote: [EMAIL PROTECTED] wrote: In the message above, I don't think you are advocating a 2.1 branch. It sounds like you believe that we should take the time to finish 2.0 before moving on. Am I right in interpreting it that way? +++1 Then I want to clarify ... you both object to the statement that developers within HTTP should be free to work on what they want. Obviously, you are both stating that we should not introduce 2.1 anytime real soon now. Therefore, you are stating that developers are not free to introduce radical new code at the present moment, and only things that fit within Apache 2.0 [subject to perpetual debate over what exactly what fits within 2.0] are open for community development efforts. Bill, I'm sorry, but you aren't reading the e-mails that have been sent. You want to branch 2.1 so that people can make radical changes. We are saying feel free to create patches with radical changes. Once people can see the patches, we can decide if they belong in 2.1, 2.0, or if we don't want them in Apache at all. You haven't read a single email on this thread. The ENTIRE POINT of this thread is that we have a radical change. Auth. Two Bills and who knows whom all else may concur that we can't reasonably force this change into 2.0 for docs and upgrade reasons. So we have a radical change. I proposed we create 2.1 to incorporate auth. Please finally go back and read the messages where people have explained why they don't want to branch. Also, as for the auth stuff, you seem to have completely ignored that Greg has offered a solution that might create backwards compat for the users with the new auth work. Greg's post does not address the Docs issue. I'm waiting for someone to offer constructive feedback. As I wrote in my response to Justin, I did try to wrap my brain around documenting both pre and post auth in the same /docs-2.0/ tree. It didn't make any sense. Perhaps someone else can do better. You are so focused on getting a 2.1 branch, that you are ignoring any other solutions to the problem that you have raised. I'm focused on persuading the HTTP group to quit messing up administrators and third party module authors. It matters very little to me if we make forward progress if we continue to treat the httpd-2.0 tree as a sandbox and alienate our third party authors and adopters. Branch 2.1 now? Only if we want to release the auth changes with all of the upgrade issues of deprecating several released module. It doesn't matter that only the names have changed, this is called deprecating a module, and it shouldn't happen within a GA release cycle on the same minor version. Bill
Re: Auth: Start the httpd-2.1 branch finally?
--On Sunday, October 13, 2002 5:15 PM -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: You haven't read a single email on this thread. The ENTIRE POINT of this thread is that we have a radical change. Auth. Two Bills and who knows whom all else may concur that we can't reasonably force this change into 2.0 for docs and upgrade reasons. Ten binding votes were cast for this change with the understanding that it might break backwards compatibility. Only one binding vote was cast for the aaa rewrite being in 2.1. Personally, I think the consensus of the group was clear. -- justin
Re: Auth: Start the httpd-2.1 branch finally?
--On Saturday, October 12, 2002 1:17 PM -0700 Aaron Bannert [EMAIL PROTECTED] wrote: That seems like a one-way street to me. How come it's ok to work on the auth changes in 2.0 but it's not ok for others? As Sander pointed out, the aaa changes were made first, then we voted on where they went. So, no, I don't see a double standard. -- justin
Re: Auth: Start the httpd-2.1 branch finally?
On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote: At 03:33 PM 10/13/2002, [EMAIL PROTECTED] wrote: On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote: At 11:40 AM 10/13/2002, Jim Jagielski wrote: [EMAIL PROTECTED] wrote: In the message above, I don't think you are advocating a 2.1 branch. It sounds like you believe that we should take the time to finish 2.0 before moving on. Am I right in interpreting it that way? +++1 Then I want to clarify ... you both object to the statement that developers within HTTP should be free to work on what they want. Obviously, you are both stating that we should not introduce 2.1 anytime real soon now. Therefore, you are stating that developers are not free to introduce radical new code at the present moment, and only things that fit within Apache 2.0 [subject to perpetual debate over what exactly what fits within 2.0] are open for community development efforts. Bill, I'm sorry, but you aren't reading the e-mails that have been sent. You want to branch 2.1 so that people can make radical changes. We are saying feel free to create patches with radical changes. Once people can see the patches, we can decide if they belong in 2.1, 2.0, or if we don't want them in Apache at all. You haven't read a single email on this thread. The ENTIRE POINT of this thread is that we have a radical change. Auth. Two Bills and who knows whom all else may concur that we can't reasonably force this change into 2.0 for docs and upgrade reasons. So we have a radical change. I proposed we create 2.1 to incorporate auth. I've read them all. We discussed this before the patch was incorporated into the release. The majority do NOT believe it is radical enough to warrant 2.1. No matter how many times you ask for 2.1 for the auth work, the majority don't believe it warrants it. Please finally go back and read the messages where people have explained why they don't want to branch. Also, as for the auth stuff, you seem to have completely ignored that Greg has offered a solution that might create backwards compat for the users with the new auth work. Greg's post does not address the Docs issue. I'm waiting for someone to offer constructive feedback. As I wrote in my response to Justin, I did try to wrap my brain around documenting both pre and post auth in the same /docs-2.0/ tree. It didn't make any sense. Perhaps someone else can do better. I will write the docs to handle both. I commit to having them done by the end of the week. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
At 05:35 PM 10/13/2002, [EMAIL PROTECTED] wrote: On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote: So we have a radical change. I proposed we create 2.1 to incorporate auth. I've read them all. We discussed this before the patch was incorporated into the release. The majority do NOT believe it is radical enough to warrant 2.1. No matter how many times you ask for 2.1 for the auth work, the majority don't believe it warrants it. And not one member of that majority has been willing to tackle the issue of supporting 2.0 with this change going into this revision. Sure it was discussed, voted upon even. Until we look squarely at the consequences of this transition, we were voting on the spirit of the changes. For example, the rename from mod_access to mod_authn_host mid-reversion is gratuitous. It just made more sense. I'm very concerned that we won't have the flexibility to rearrange this further, by trying to prevent user confusion. Of course, the few loud voices clearly aren't concerned about the confusion factor in the first place, so I suppose such concerns won't halt progress going forward. Please finally go back and read the messages where people have explained why they don't want to branch. Also, as for the auth stuff, you seem to have completely ignored that Greg has offered a solution that might create backwards compat for the users with the new auth work. Greg's post does not address the Docs issue. I'm waiting for someone to offer constructive feedback. As I wrote in my response to Justin, I did try to wrap my brain around documenting both pre and post auth in the same /docs-2.0/ tree. It didn't make any sense. Perhaps someone else can do better. I will write the docs to handle both. I commit to having them done by the end of the week. Don't be too stubborn to surrender after you start, though, if it isn't going the way you would like :-) Without any sarcasm, thank you for attacking this, and I'm looking forward to reading them. Bill
Re: Auth: Start the httpd-2.1 branch finally?
William A. Rowe, Jr. wrote: You haven't read a single email on this thread. The ENTIRE POINT of this thread is that we have a radical change. Auth. Two Bills and who knows whom all else may concur that we can't reasonably force this change into 2.0 for docs and upgrade reasons. So we have a radical change. I proposed we create 2.1 to incorporate auth. Branch 2.1 now? Only if we want to release the auth changes with all of the upgrade issues of deprecating several released module. It doesn't matter that only the names have changed, this is called deprecating a module, and it shouldn't happen within a GA release cycle on the same minor version. But we've done it before... IIRC the referer logging module for example. I 100% appreciate your POV that a bump to 2.1 makes the change even more substantial and cleaner. However, I think the group consensus is that the time to branch off a 2.1 isn't quite ready yet. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Auth: Start the httpd-2.1 branch finally?
At 05:33 PM 10/13/2002, Justin Erenkrantz wrote: --On Sunday, October 13, 2002 5:15 PM -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: You haven't read a single email on this thread. The ENTIRE POINT of this thread is that we have a radical change. Auth. Two Bills and who knows whom all else may concur that we can't reasonably force this change into 2.0 for docs and upgrade reasons. Ten binding votes were cast for this change with the understanding that it might break backwards compatibility. Only one binding vote was cast for the aaa rewrite being in 2.1. First, anyone can vote. Only committers have vetos. 2.0: rbb, brianp, dreid, gstein, jim, rederpj, striker, trawick, ianh, gs, bnicholes 2.1: dpejesh, chris, aaron, hb Note that neither Bill voted, apparently that would be six votes for 2.1. But you are ignoring that striker has already implicitly voted against 2.0 by releasing 2.0.42 sans auth changes. And I released 2.0.43 sans auth changes. I said, I'm not vetoing without three strong -1's on this code. I'm not certain Bill's concerns are addressed. I'm not certain Aaron's are addressed. After I get strong -1's, I'll personally veto. Then we can resume the 2.1 branch discussion as a separate point. And I would like to see what rbb creates for documentation. That will affect my -1, at least. Personally, I think the consensus of the group was clear. -- justin This was the very definition of a non-consensus decision. Main Entry: con·sen·sus 1 a : general agreement : UNANIMITY the consensus of their opinion, based on reports... from the border -- John Hersey b : the judgment arrived at by most of those concerned the consensus was to go ahead © 2002 by Merriam-Webster, Incorporated
Re: Auth: Start the httpd-2.1 branch finally?
* rbb wrote: On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote: I did try to wrap my brain around documenting both pre and post auth in the same /docs-2.0/ tree. It didn't make any sense. Perhaps someone else can do better. I will write the docs to handle both. I commit to having them done by the end of the week. I've tried to find a solution. It's certainly not complete, but a first suggestion. I simply fetched the old module docs from the Attic, named them obs_* and modified the xslt a little bit. As proposed by Joshua they got the status Obsolete and also a large warning on top of the page. The modules are listed on module index http://cvs.apache.org/~nd/manual/mod/ below all other modules and on the sitemap the same way: http://cvs.apache.org/~nd/manual/sitemap.html However, the directives don't appear in directive indexes (because of status='obsolete'). The whole patch can be found here: http://cvs.apache.org/~nd/obs.patch I think we need a document that explains exactly the changes and the new provider mechanism, so we may set links from both (pre and post) module docs. Comments, further suggestions and flames are welcome. nd -- Die Untergeschosse der Sempergalerie bleiben währenddessen aus statistischen Gründen geflutet. -- Spiegel Online
Re: Auth: Start the httpd-2.1 branch finally?
André Malo wrote: I've tried to find a solution. It's certainly not complete, but a first suggestion. I simply fetched the old module docs from the Attic, named them obs_* and modified the xslt a little bit. As proposed by Joshua they got the status Obsolete and also a large warning on top of the page. The modules are listed on module index http://cvs.apache.org/~nd/manual/mod/ +1. That is about what I had in mind. The note at the top could be improved a little. Something along the lines, This module was replaced in version 2.0.44 and greater by modulemod_.../module (and mod_...). For more information, see ... I think we need a document that explains exactly the changes and the new provider mechanism, so we may set links from both (pre and post) module docs. Absolutely essential before the next release. If it is simple it can go in upgrading.html. If it is complicated, it should get a separate doc and be linked from there. One more note: I'd like to see the rename of mod_access reversed. That just seems like a gratuitous change that hurts users and doesn't really help developers. Joshua.
Re: Auth: Start the httpd-2.1 branch finally?
--On Sunday, October 13, 2002 9:36 PM -0400 Joshua Slive [EMAIL PROTECTED] wrote: One more note: I'd like to see the rename of mod_access reversed. That just seems like a gratuitous change that hurts users and doesn't really help developers. Could you please explain why breaking out the authorization (authz) components in a similar fashion to authentication (authn) is a gratuitous change? I believe mod_authz_host is a much better name for mod_access. It indicates that this module is only dealing with authorization based on the remote host components. mod_access can mean lots of things, but the fact that it was solely restricted to hostnames wasn't obvious to me from the original module name. -- justin
Re: Auth: Start the httpd-2.1 branch finally?
At 08:36 PM 10/13/2002, Joshua Slive wrote: André Malo wrote: I've tried to find a solution. It's certainly not complete, but a first suggestion. I simply fetched the old module docs from the Attic, named them obs_* and modified the xslt a little bit. As proposed by Joshua they got the status Obsolete and also a large warning on top of the page. The modules are listed on module index http://cvs.apache.org/~nd/manual/mod/ +1. That is about what I had in mind. The note at the top could be improved a little. Something along the lines, This module was replaced in version 2.0.44 and greater by modulemod_.../module (and mod_...). For more information, see ... I think we need a document that explains exactly the changes and the new provider mechanism, so we may set links from both (pre and post) module docs. Absolutely essential before the next release. If it is simple it can go in upgrading.html. If it is complicated, it should get a separate doc and be linked from there. One more note: I'd like to see the rename of mod_access reversed. That just seems like a gratuitous change that hurts users and doesn't really help developers. On that same thought... mod_auth_basic is equally obtuse. Renaming it back to mod_auth doesn't seem like a stretch (if you consider that the simplest auth is basic.) Of course, we don't lose the ability to leave mod_auth unloaded and simply load mod_auth_digest. Obviously, loading mod_authn_file, mod_authn_default, mod_authz_file, mod_authz_default, mod_authz_groupfile, mod_authz_host, and mod_authz_user are going to be required to retain behavior that folks are expecting. But at least the renames could go. BTW André, nice start. I'd call out mod_auth (prior to 2.0.44) as it's index entry, if we keep the mod_auth_basic concept. Likewise for mod_access. Bill Bill
Re: Auth: Start the httpd-2.1 branch finally?
On Sun, 13 Oct 2002, Justin Erenkrantz wrote: --On Sunday, October 13, 2002 9:36 PM -0400 Joshua Slive [EMAIL PROTECTED] wrote: One more note: I'd like to see the rename of mod_access reversed. That just seems like a gratuitous change that hurts users and doesn't really help developers. Could you please explain why breaking out the authorization (authz) components in a similar fashion to authentication (authn) is a gratuitous change? Justin, he said the name change was gratuitous, not the change itself. I believe mod_authz_host is a much better name for mod_access. It indicates that this module is only dealing with authorization based on the remote host components. mod_access can mean lots of things, but the fact that it was solely restricted to hostnames wasn't obvious to me from the original module name. -- justin It may not have been obvious to you, but anybody who has been using Apache for the last few years has always known this. I happen to agree, the name change does make more sense, but it wasn't necessary for the patch. Please change the name back. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
On Fri, 2002-10-11 at 20:59, William A. Rowe, Jr. wrote: Let's get cracking and we can have a 2.1 release out by year end, depending on how far we go with changes in that version. Certainly some of the file-based stuff can finally be separated out, even if not as radically as GStein has proposed. There's one thing about this proposal that I really like: It creates a schedule goal for 2.1. In the past, I've been opposed to jumping to 2.1 because it was so vaguely defined that one couldn't be sure if delaying a feature to 2.1 meant it will be out next quarter or it will be out in a few years. If we can build consensus around a 2.1 with a limited feature set and schedule, them I'm much more interested... I don't have a strong opinion about the authn redesign, but I do have one change in mind that would fit well in 2.1: async write support. And async read support, but that may take a lot longer. Brian
