You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2001/09/06 14:01:22 UTC
Proposal: Future release strategies
Hi all,
Before anyone can make any decision on the fate of mod_ssl, mod_proxy,
mod_ldap, etc - we need to make a decision on how Apache v2.0 and it's
submodules are to be released in their final form. This gives us a goal
to work towards when we make a decision about what goes where and how.
Before we can make this decision, we need to know what the requirements
for such a release are. I would make an initial stab at this:
o Any release should be simple and straightforward from a user
perspective
o Any release should be simple and straightforward from a developer
perspective
o There must be a clear understanding by the user as to which modules
are "official ASF well supported blessed good quality modules" and which
are 3rd party non-ASF modules.
o There must be a clear understanding of what modules a website
developer can expect to be available to them when they have "Apache
installed at their site". We need to acknowledge that Apache is
installed at many hosted environments where end users have litte or no
control over what modules are included and what modules are not by a
system administrator.
Going from the above requirements, I would suggest a release strategy
like this:
o We release apr-x.x.x.tar.gz containing APR, which can be installed
separately (this is the direction APR seems to be going, we should
follow it through to it's logical conclusion).
o We release apache-core-2.x.x.tar.gz containing the basic webserver and
basic core modules.
o We release apache-modules-2.x.x.tar.gz containing mod_proxy,
mod_ldap, mod_ssl, mod_gz
** OR **
We release apache-proxy-2.x.x.tar.gz, apache-ssl-2.x.x.tar.gz,
apache-ldap-2.x.x.gz
Some points about the above release:
- The official "blessed" ASF supported modules mod_ssl et al are
released with the prefix "apache-". This clearly demonstrates to the end
user that this is an official ASF supported module, and they know what
quality to expect from it.
- When a "release" is made, the apache-core and the apache-modules are
made at the same time. The different archives are simply a result of the
automated rollup process, and are *not* different projects nor are they
released separately (otherwise they would simply confuse the hell out of
end users).
What needs to be done to achieve the above:
o APR needs to be made to be buildable and releasable on it's own
(assuming this is not already possible).
o Each of mod_ssl, mod_proxy and mod_ldap needs to be stripped into it's
own archive, and the rollup script needs to be modified to produce a
rollup tarball for these modules (or combined module).
o The build procedures for mod_ssl, mod_proxy and mod_ldap need to be
modified so that they are buildable outside the Apache tree.
The stuff I've put down are just suggestions - please tell me if I am
barking up the wrong tree...
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Proposal: Future release strategies
Posted by Graham Leggett <mi...@sharp.fm>.
Ryan Bloom wrote:
> You missed my point. Your original message said that the first step was to
> release APR. That is incorrect. We do not release APR on this list, and if
> that is our first step, then it is broken. We can either use a previously released
> version of APR, or we can use a timed checkout. APR should always never
> be removing an API, once it is released, so we should be safe however.
Ok - you're right... The whole thing was a suggestion as "first prize" -
APR doesn't have to be separate just yet.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Proposal: Future release strategies
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 06 September 2001 09:42, Graham Leggett wrote:
> Ryan Bloom wrote:
> > We have no control over APR. APR will not make a release just because
> > the web server wants it to. Apache needs to either use an already
> > released APR, or it needs to specify a date/time to check out APR.
>
> We have no control over libc either, and yet we use that. Surely we can
> just consider APR a necessary external library that we link against -
> which has it's own release schedule - or is APR still too closely tied
> up with Apache for this to be practical?
You missed my point. Your original message said that the first step was to
release APR. That is incorrect. We do not release APR on this list, and if
that is our first step, then it is broken. We can either use a previously released
version of APR, or we can use a timed checkout. APR should always never
be removing an API, once it is released, so we should be safe however.
I just refuse to let our first step be "release APR".
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Proposal: Future release strategies
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 02:47 PM 09/06/2001, Bill Stoddard wrote:
> > Well - the vote on the table is to take the LDAP code out of
> Apache v2.0
> > - but the next question is when it's removed, what do we do with
> it?
>
>I will probably be a user of mod_ldap, but right now, I am inclined
>to remove it from the
>core and put it in its own repository for the same reasons I want to
>keep mod_gz out.
Why not just put them in modules/experimental? Isn't that what it's
for?
--
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
Re: Proposal: Future release strategies
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Ryan Bloom" <rb...@covalent.net> wrote:
> On Thursday 06 September 2001 11:47, Bill Stoddard wrote:
>>> Ryan Bloom wrote:
>>>> We have no control over APR. APR will not make a release just because
>>>> the web server wants it to. Apache needs to either use an already
>>>> released APR, or it needs to specify a date/time to check out APR.
>>>
>>> We have no control over libc either, and yet we use that. Surely we can
>>> just consider APR a necessary external library that we link against -
>>> which has it's own release schedule - or is APR still too closely tied
>>> up with Apache for this to be practical?
>>
>> I think APR is still changing too much for this to be practical. IMO, it
>> would be a serious mistake to attempt to ship apache httpd 2.0 w/o
>> including a copy of APR that has been tested with the server. APR is not
>> (yet) libc.
>
> Thie big problem with this, is being able to reproduce from CVS. It may mean
> that we have to include a timestamp in buildconf when we tell people to check
> out APR. The problem is that if I go check-out httpd-2.0.30, I don't want to
> find a tag in APR that says APACHE_2_0_30 and check that out, I want to
> grab APR_1_0_1.
Being one of the few who uses APR outside the scope of HTTPD (I know only of
Subversion ATM using the lib for things different from the web server), yes,
I agree that it would be so cool to have an APR tag to rely on to reproduce
past builds. But I see Bill's point on saying that APR is not ready for
prime time yet, putting a tag right now would be (IMVVVVVVVHO) as checking
out with a specified date.
What I do when rolling a "milestone" of WebApp is that I "declare" a
date/time stamp I am more or less sure is working, testing it out, make a
snapshot, and include it with my source distrib... It has worked pretty well
in the last few months, and I couldn't ask for more since I was already able
to remove any possible "#ifdef NAME_YOUR_PLATFORM" from my code...
And if there's a bug, oh well, it's still alpha code :) Check out HEAD and
redo the whole thing again (takes me less time than figuring out all
platform dependancies anyway!)
Pier
Re: Proposal: Future release strategies
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 06 September 2001 11:47, Bill Stoddard wrote:
> > Ryan Bloom wrote:
> > > We have no control over APR. APR will not make a release just because
> > > the web server wants it to. Apache needs to either use an already
> > > released APR, or it needs to specify a date/time to check out APR.
> >
> > We have no control over libc either, and yet we use that. Surely we can
> > just consider APR a necessary external library that we link against -
> > which has it's own release schedule - or is APR still too closely tied
> > up with Apache for this to be practical?
>
> I think APR is still changing too much for this to be practical. IMO, it
> would be a serious mistake to attempt to ship apache httpd 2.0 w/o
> including a copy of APR that has been tested with the server. APR is not
> (yet) libc.
Thie big problem with this, is being able to reproduce from CVS. It may mean
that we have to include a timestamp in buildconf when we tell people to check
out APR. The problem is that if I go check-out httpd-2.0.30, I don't want to
find a tag in APR that says APACHE_2_0_30 and check that out, I want to
grab APR_1_0_1.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Proposal: Future release strategies
Posted by Graham Leggett <mi...@sharp.fm>.
Bill Stoddard wrote:
> +1 on mod_ssl and mod_proxy being included in the core. The last vote we had also
> supported mod_proxy in the core. As far as I am concerned, mod_proxy can go in today...
We did get the +1's we needed...
How about this: I will commit the v2.0 mod_proxy back to the core after
I get back from Hamburg on sunday, unless there are any objections
between now and then.
> I will probably be a user of mod_ldap, but right now, I am inclined to remove it from the
> core and put it in its own repository for the same reasons I want to keep mod_gz out. For
> now. I'd love to see mod_ldap come into the core in 2.1. Along with mod_esi... :-)
Would an alternative suggestion be to move it the experimental
directory?
We could let it prove it's worth there while not affecting the rest of
the server or it's stability.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Proposal: Future release strategies
Posted by Bill Stoddard <bi...@wstoddard.com>.
> Ryan Bloom wrote:
>
> > We have no control over APR. APR will not make a release just because
> > the web server wants it to. Apache needs to either use an already released
> > APR, or it needs to specify a date/time to check out APR.
>
> We have no control over libc either, and yet we use that. Surely we can
> just consider APR a necessary external library that we link against -
> which has it's own release schedule - or is APR still too closely tied
> up with Apache for this to be practical?
>
I think APR is still changing too much for this to be practical. IMO, it would be a
serious mistake to attempt to ship apache httpd 2.0 w/o including a copy of APR that has
been tested with the server. APR is not (yet) libc.
> > > o Each of mod_ssl, mod_proxy and mod_ldap needs to be stripped into it's
> > > own archive, and the rollup script needs to be modified to produce a
> > > rollup tarball for these modules (or combined module).
> >
> > Woah. Mod_ssl was put into the core for a reason. I don't want to remove it
> > unless everybody wants to.
>
> I included it here because people mentioned that there were potential
> import/export problems still in some parts of the world. It's not that
> critical either way - in fact it is much more convenient if it is
> included inside the core.
+1 on mod_ssl and mod_proxy being included in the core. The last vote we had also
supported mod_proxy in the core. As far as I am concerned, mod_proxy can go in today...
>
> > I am not sure that I even believe mod_ldap should
> > be a sub-project either. I don't remember ever having that conversation. But,
> > I will not stand in the way of it.
>
> Well - the vote on the table is to take the LDAP code out of Apache v2.0
> - but the next question is when it's removed, what do we do with it? I'm
> not keen on seeing it sit in limbo like mod_proxy has been for a while,
> which is why I would like to see something resolved on the rollup issue.
>
I will probably be a user of mod_ldap, but right now, I am inclined to remove it from the
core and put it in its own repository for the same reasons I want to keep mod_gz out. For
now. I'd love to see mod_ldap come into the core in 2.1. Along with mod_esi... :-)
Bill
Re: Proposal: Future release strategies
Posted by Graham Leggett <mi...@sharp.fm>.
Ryan Bloom wrote:
> We have no control over APR. APR will not make a release just because
> the web server wants it to. Apache needs to either use an already released
> APR, or it needs to specify a date/time to check out APR.
We have no control over libc either, and yet we use that. Surely we can
just consider APR a necessary external library that we link against -
which has it's own release schedule - or is APR still too closely tied
up with Apache for this to be practical?
> > o Each of mod_ssl, mod_proxy and mod_ldap needs to be stripped into it's
> > own archive, and the rollup script needs to be modified to produce a
> > rollup tarball for these modules (or combined module).
>
> Woah. Mod_ssl was put into the core for a reason. I don't want to remove it
> unless everybody wants to.
I included it here because people mentioned that there were potential
import/export problems still in some parts of the world. It's not that
critical either way - in fact it is much more convenient if it is
included inside the core.
> I am not sure that I even believe mod_ldap should
> be a sub-project either. I don't remember ever having that conversation. But,
> I will not stand in the way of it.
Well - the vote on the table is to take the LDAP code out of Apache v2.0
- but the next question is when it's removed, what do we do with it? I'm
not keen on seeing it sit in limbo like mod_proxy has been for a while,
which is why I would like to see something resolved on the rollup issue.
> > o The build procedures for mod_ssl, mod_proxy and mod_ldap need to be
> > modified so that they are buildable outside the Apache tree.
>
> No. They should use the config.m4 mechanism. We are releasing them as
> source, and they can easily be built inside the tree. What's more, we can
> easily use apxs to build them outside the tree.
*We* could do these things easily, but I am thinking about the end user.
When they download something they expect to get a tarball, open it up,
go ./configure ; make ; make install. If all the ./configure script does
is locate apxs and installed apache headers and builds the source that
way that's fine - but we need to follow the path of least astonishment
for the users.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Proposal: Future release strategies
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 06 September 2001 05:01, Graham Leggett wrote:
> o We release apr-x.x.x.tar.gz containing APR, which can be installed
> separately (this is the direction APR seems to be going, we should
> follow it through to it's logical conclusion).
We have no control over APR. APR will not make a release just because
the web server wants it to. Apache needs to either use an already released
APR, or it needs to specify a date/time to check out APR.
> o APR needs to be made to be buildable and releasable on it's own
> (assuming this is not already possible).
APR is buildable on it's own, but people need to work on getting APR to a release
state.
> o Each of mod_ssl, mod_proxy and mod_ldap needs to be stripped into it's
> own archive, and the rollup script needs to be modified to produce a
> rollup tarball for these modules (or combined module).
Woah. Mod_ssl was put into the core for a reason. I don't want to remove it
unless everybody wants to. I am not sure that I even believe mod_ldap should
be a sub-project either. I don't remember ever having that conversation. But,
I will not stand in the way of it.
> o The build procedures for mod_ssl, mod_proxy and mod_ldap need to be
> modified so that they are buildable outside the Apache tree.
No. They should use the config.m4 mechanism. We are releasing them as
source, and they can easily be built inside the tree. What's more, we can
easily use apxs to build them outside the tree.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------