You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/08/28 21:25:36 UTC
Going to 2.1? was Re: authentication rewrite
On Wed, Aug 28, 2002 at 11:57:42AM -0700, Aaron Bannert wrote:
> This is a big enough of a change that I would be willing to allow
> for a branch to 2.1 at this point (not a full new repository, just
> a cvs branch) so that you and others who are interested can work on
> the auth stuff, and so we don't break the configs in 2.0's auth.
branches in CVS are awful (perhaps not so with SVN though).
Not to mention our repository is "httpd-2.0" - I don't think it makes
sense to have a 2.1 in there.
I'm not entirely sold on splitting off to a 2.1 yet, but I think we
now have something where it is worth discussing it. -- justin
Re: Going to 2.1? was Re: authentication rewrite
Posted by Justin Erenkrantz <je...@apache.org>.
On Wed, Aug 28, 2002 at 02:56:10PM -0700, Greg Stein wrote:
> Well... this auth stuff doesn't even change the API. It provides a new
> opt-in arrangement for authenticating.
>
> (no new APIs for authz, tho; the code is just being refactored rather than
> new APIs to support that; the auth_checker hook is sufficient)
Can we agree on the name for the authn/authz split that Dirk has, do
the refactoring, and then come back later and add backwards compat
with directives?
My concern is that we may not be able to provide backwards compat
and then we effectively managed to hork 2.0. -- justin
Re: Going to 2.1? was Re: authentication rewrite
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Aug 28, 2002 at 11:15:14PM +0200, Dirk-Willem van Gulik wrote:
>
> > IMO, we shouldn't branch, and we shouldn't bother with a version bump. I
> > think we can ensure backwards compat for the directives, and only minor
> > changes in the modules which need to be LoadModule'd. That is quite fine for
>
> Aye - it is more the API than the directives.
Well... this auth stuff doesn't even change the API. It provides a new
opt-in arrangement for authenticating.
(no new APIs for authz, tho; the code is just being refactored rather than
new APIs to support that; the auth_checker hook is sufficient)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Going to 2.1? was Re: authentication rewrite
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> IMO, we shouldn't branch, and we shouldn't bother with a version bump. I
> think we can ensure backwards compat for the directives, and only minor
> changes in the modules which need to be LoadModule'd. That is quite fine for
Aye - it is more the API than the directives.
Dw
Re: Going to 2.1? was Re: authentication rewrite
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Aug 28, 2002 at 10:46:03PM +0200, Dirk-Willem van Gulik wrote:
>
> > branches in CVS are awful (perhaps not so with SVN though).
>
> Actually - the branching is trivial - it is the merging or the MFC which
> is a bit of a pain. I'd not worry about it. Take a look at the FreeBSD
> crowd who maintains several stable/release/current branches with
> relatively little overhead.
If anything, we'd branch 2.0 and keep the trunk as 2.1 development. As bugs
are fixed on the trunk, they'd be "ported" over to the 2.0 branch.
IMO, we shouldn't branch, and we shouldn't bother with a version bump. I
think we can ensure backwards compat for the directives, and only minor
changes in the modules which need to be LoadModule'd. That is quite fine for
a 2.0.x release.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Going to 2.1? was Re: authentication rewrite
Posted by Jim Jagielski <ji...@jaguNET.com>.
A few points/concerns:
At 1:15 PM -0700 8/28/02, Aaron Bannert wrote:
>On Wed, Aug 28, 2002 at 03:42:53PM -0400, Ryan Bloom wrote:
>> Just the same one I've had all along. Fix it in 2.0. If it is a major
>> config change, then we document it. We have made changes like this
>> before.
>
>I would consider this to be part of 2.0, even if we call it 2.1.
>Let me broaden this up a little with some general goals that I
>consider to be important. Let's take each of these goals on their
>own and consider their merit or feasibility:
>
>1) More frequent releases
Of course, not if it means each new release destroys some sort
of backwards compatibility. It would be painful, IMO, in this
particular case to hit someone who just made the transition to
2.0 to then be hit with a 2.1 upgrade.
We need to recall that in addition to a large developer community,
there's also a much larger *user* one :)
>2) We target the auth features for a release we will call 2.1
unless things are horribly wrong with the 2.0, which they aren't
*that* bad, then this would by personal choice. Again, this is mostly
with my "user community" hat on.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] 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: Going to 2.1? was Re: authentication rewrite
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Aug 28, 2002 at 03:42:53PM -0400, Ryan Bloom wrote:
> Just the same one I've had all along. Fix it in 2.0. If it is a major
> config change, then we document it. We have made changes like this
> before.
I would consider this to be part of 2.0, even if we call it 2.1.
Let me broaden this up a little with some general goals that I
consider to be important. Let's take each of these goals on their
own and consider their merit or feasibility:
1) More frequent releases
- By making releases more often, we can help foster a healthy
testing community that can provide valuable feedback and
eventually improve the quality of the server. We don't need
to restrict ourselves to the ASF-cabal-approved official release,
nor the opposite extreme nightly snapshots (which connote no
amount of quality, stability, or features).
2) Well-defined features
- There is sort of a catch-22 here. Our volunteer work on features within
the server can not be constrained by a deadline, but it would be good
to identify major and minor changes and feature additions and give them
an appropriately incremented revision number. Later our users can
go into our documentation and find out, for example, what it means
when 2.1 has a new authentication framework. (Remember, revision numbers
are free, but providing clear and precise information to our users
comes at a steep price.)
3) Fostering a healthy testing community
- This is one area that I believe the HTTP Server Project has failed
miserably compared to other projects of equal popularity, at least
as long as I have been involved. I also believe this is a direct
result of the failure to identify the above problems. People want
to play with new features, but they need to know what those features
are before they start to play. We also have to give them something
to play with, which means rapid-fire releases with well-documented
features.
In the short term I propose the following:
1) We start work on a new auth framework in whatever way is most comfortable
for those who will work on it -- either in the 2.0 tree or in a branch
or whatever. (Ideally we don't break the config on this rather large
piece without at least a minor-revision bump.)
2) We target the auth features for a release we will call 2.1
3) We maintain this pace for any new features that arise, and decide
on a per-feature bases whether it fits in the current minor revision,
in a new minor-revision, or in a new major-revision.
-aaron
Re: Going to 2.1? was Re: authentication rewrite
Posted by rb...@apache.org.
On Wed, 28 Aug 2002, Aaron Bannert wrote:
> On Wed, Aug 28, 2002 at 12:25:36PM -0700, Justin Erenkrantz wrote:
> > branches in CVS are awful (perhaps not so with SVN though).
>
> I have only heard anecdotal evidence for this, but have actually
> used cvs branches on other large and very successful projects
> before. (*cough* PHP! *ahem*). I'd rather see a cvs branch than
> a whole new copy of the repository. We can wait until the 3.0
> cycle to switch to SVN or start a new repository if we want.
>
> > Not to mention our repository is "httpd-2.0" - I don't think it makes
> > sense to have a 2.1 in there.
> >
> > I'm not entirely sold on splitting off to a 2.1 yet, but I think we
> > now have something where it is worth discussing it. -- justin
>
> I'd really like to see us start attacking smaller-grain problems
> and releasing those features more often, rather than lining up years
> and years of "ooh me too and this too" until we've got bugs coming
> out of our ears and nothing stable out the door for our users and
> testers. IMHO, a new auth framework is a *perfect* target for the
> next milestone, and it makes sense to call it 2.1.
>
> Any other opinions?
Just the same one I've had all along. Fix it in 2.0. If it is a major
config change, then we document it. We have made changes like this
before.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: Going to 2.1? was Re: authentication rewrite
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Aug 28, 2002 at 12:25:36PM -0700, Justin Erenkrantz wrote:
> branches in CVS are awful (perhaps not so with SVN though).
I have only heard anecdotal evidence for this, but have actually
used cvs branches on other large and very successful projects
before. (*cough* PHP! *ahem*). I'd rather see a cvs branch than
a whole new copy of the repository. We can wait until the 3.0
cycle to switch to SVN or start a new repository if we want.
> Not to mention our repository is "httpd-2.0" - I don't think it makes
> sense to have a 2.1 in there.
>
> I'm not entirely sold on splitting off to a 2.1 yet, but I think we
> now have something where it is worth discussing it. -- justin
I'd really like to see us start attacking smaller-grain problems
and releasing those features more often, rather than lining up years
and years of "ooh me too and this too" until we've got bugs coming
out of our ears and nothing stable out the door for our users and
testers. IMHO, a new auth framework is a *perfect* target for the
next milestone, and it makes sense to call it 2.1.
Any other opinions?
-aaron
Re: Going to 2.1? was Re: authentication rewrite
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> branches in CVS are awful (perhaps not so with SVN though).
Actually - the branching is trivial - it is the merging or the MFC which
is a bit of a pain. I'd not worry about it. Take a look at the FreeBSD
crowd who maintains several stable/release/current branches with
relatively little overhead.
Dw
RE: Going to 2.1? was Re: authentication rewrite
Posted by "John K. Sterling" <jo...@sterls.com>.
If we do wait for 2.1, it would give us the opportunity to collaborate and
make this really clean......you could just create a repository for the new
auth modules (even on sourceforge or something) - assuming not too many
core changes are required.
sterling
>-- Original Message --
>Reply-To: dev@httpd.apache.org
>Date: Wed, 28 Aug 2002 12:25:36 -0700
>From: Justin Erenkrantz <je...@apache.org>
>To: Aaron Bannert <aa...@clove.org>, dev@httpd.apache.org
>Subject: Going to 2.1? was Re: authentication rewrite
>
>
>On Wed, Aug 28, 2002 at 11:57:42AM -0700, Aaron Bannert wrote:
>> This is a big enough of a change that I would be willing to allow
>> for a branch to 2.1 at this point (not a full new repository, just
>> a cvs branch) so that you and others who are interested can work on
>> the auth stuff, and so we don't break the configs in 2.0's auth.
>
>branches in CVS are awful (perhaps not so with SVN though).
>
>Not to mention our repository is "httpd-2.0" - I don't think it makes
>sense to have a 2.1 in there.
>
>I'm not entirely sold on splitting off to a 2.1 yet, but I think we
>now have something where it is worth discussing it. -- justin