You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 2001/09/06 17:53:50 UTC
Re: cvs commit: httpd-2.0 STATUS
* On 2001-09-06 at 11:51,
rbb@apache.org <rb...@apache.org> excited the electrons to say:
>
> I am veto'ing this, for now at least. I will support making mod_gz
> a separate sub-project of httpd, and possibly rolling it into a later
> release of 2.0, but now is not the time to do this.
Vetos need a valid technical justification, not just an opinion..
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: cvs commit: httpd-2.0 STATUS
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 06 September 2001 08:53, Rodent of Unusual Size wrote:
> * On 2001-09-06 at 11:51,
>
> rbb@apache.org <rb...@apache.org> excited the electrons to say:
> > I am veto'ing this, for now at least. I will support making mod_gz
> > a separate sub-project of httpd, and possibly rolling it into a later
> > release of 2.0, but now is not the time to do this.
>
> Vetos need a valid technical justification, not just an opinion..
Yes they do, and the valid technical reason is that the core doesn't need
this right now, it does not fulfill all of the criteria that people have posted
to dev@httpd. This is also the wrong time to be adding new modules to the
core. This can easily wait until 2.1, when we can make a more informed
decision about it.
Many people have said that adding modules to the core should not be
done haphazardly, and this feels like it is being done haphazardly. I do not
want to regret doing this a few months from now, so I want to take adding this
module to the core slowly. I feel like it is being rammed down our throats, and
I don't like that.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0 STATUS
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Sep 06, 2001 at 03:03:16PM -0700, William A. Rowe, Jr. wrote:
> If it's stable and works, but clearly isn't a 'known quantity' in production
> servers, it must land in modules/experimental until it's interaction with the
> many clients is well understood. Compiling isn't the issue, usability is
> (just like mod_auth_digest back in the 1.3 tree.)
Would that be a fair compromise here? -- justin
Re: cvs commit: httpd-2.0 STATUS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Justin Erenkrantz" <je...@ebuilt.com>
Sent: Thursday, September 06, 2001 2:56 PM
> On Thu, Sep 06, 2001 at 02:49:56PM -0700, Ryan Bloom wrote:
> > If the module is a part of the server, then it must work before the server
> > is production ready. You can't have a module that doesn't work in a server
> > that is going GA, it doesn't make sense. You will find if you read the
> > archives, that we have cancelled releases in the past, because a single
> > module did not work correctly. Anytime you put something into the core,
> > you take the very real chance of delaying the core server.
>
> I thought that we didn't follow the policy with certain modules.
> AIUI, mod_ssl is exempt from this. Why not mod_gz as well? Or, as
> some have suggested - stick it in modules/experimental?
mod_ssl is not exempt from this. It was decided over a year ago that ssl should
be supported in Apache 2.0, and about a year ago that became possible due to
relaxation of the crypto export regulations for open source within the US.
The mod_ssl will _not_ be unsupported or incomplete when we go GA. The fact is,
mod_ssl itself was a very stable piece of code. It has undergone a facelift in
conversion to 2.0, and this is far more likely to expose our existing 2.0 bugs
than introduce new bugs from mod_ssl.
> I'd also like to point out that no one has said that the module
> didn't work as expected. I tested it before I submitted it with
> my +1. If it doesn't work, it'd be fixed.
If it's stable and works, but clearly isn't a 'known quantity' in production
servers, it must land in modules/experimental until it's interaction with the
many clients is well understood. Compiling isn't the issue, usability is
(just like mod_auth_digest back in the 1.3 tree.)
Re: cvs commit: httpd-2.0 STATUS
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Justin Erenkrantz wrote:
>
> FWIW, I don't thinking creating a sub-project for one file makes
> a lot of sense. -- justin
I agree with Justin on this, and disagree with FirstBill and Ryan.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: cvs commit: httpd-2.0 STATUS
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 6 Sep 2001, Justin Erenkrantz wrote:
> > Anytime you put something into the core,
> > you take the very real chance of delaying the core server.
>
> Or, as some have suggested - stick it in modules/experimental?
As Ken pointed out, modules in the experimental directory have
historically NOT delayed server releases. +1 to put mod_gz in there if
that's what it takes to get agreement on this issue.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: httpd-2.0 STATUS
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Sep 06, 2001 at 02:49:56PM -0700, Ryan Bloom wrote:
> If the module is a part of the server, then it must work before the server
> is production ready. You can't have a module that doesn't work in a server
> that is going GA, it doesn't make sense. You will find if you read the
> archives, that we have cancelled releases in the past, because a single
> module did not work correctly. Anytime you put something into the core,
> you take the very real chance of delaying the core server.
I thought that we didn't follow the policy with certain modules.
AIUI, mod_ssl is exempt from this. Why not mod_gz as well? Or, as
some have suggested - stick it in modules/experimental?
I'd also like to point out that no one has said that the module
didn't work as expected. I tested it before I submitted it with
my +1. If it doesn't work, it'd be fixed.
FWIW, I don't thinking creating a sub-project for one file makes
a lot of sense. -- justin
Re: cvs commit: httpd-2.0 STATUS
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ryan Bloom wrote:
>
> If the module is a part of the server, then it must work
> before the server is production ready. You can't have a
> module that doesn't work in a server that is going GA,
> it doesn't make sense. You will find if you read the
> archives, that we have cancelled releases in the past,
> because a single module did not work correctly.
I believe that none of the above are true for modules
in the experimental directory. I believe such have a long
history of having build or run-time failures which have had
no impact on releases whatsoever. They eventually get
fixed, but they in no way have been a blocking factor.
I still do not think your veto is valid here, Ryan, at
least when applied to the subject of putting mod_gz in
experimental. Anywhere else, and the only criterion I
consider valid from your list is failing to meet the
consensually-decided requirements. The rest still sounds
like opinion to me.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: cvs commit: httpd-2.0 STATUS
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 6 Sep 2001, Ryan Bloom wrote:
> You will find if you read the archives, that we have cancelled
> releases in the past, because a single module did not work correctly.
> Anytime you put something into the core, you take the very real chance
> of delaying the core server.
This is true enough.
> This is why I am against putting everything into the core. The core should
> be as small as possible, so that an individual module doesn't hold up
> releases.
We must be wary of how MANY things we remove from the core distribution,
because it's often (of course not always) the case that when we see
problems with core modules, it's really the module exposing a flaw in the
core itself. Without the modules, we'd probably never be able to test the
core well enough to declare it stable. This has lately been the case with
mod_include, mod_dir, mod_rewrite, mod_ssl, etc. Those modules have
certainly each had their own problems now and then, but they've also
helped us sniff out major problems in the core. I'm not saying that this
necessarily applies to mod_gz, but you get my point.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: httpd-2.0 STATUS
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 06 September 2001 14:45, Justin Erenkrantz wrote:
> On Thu, Sep 06, 2001 at 02:39:18PM -0400, Bill Stoddard wrote:
> > +1 on the veto :-)
> >
> > I am a strong +1 in favor of making this a subproject and probably
> > rolling it into a post 2.0 release. The presence of mod_gz in the core
> > now -will- impact folks who are working on stabilizing the server.
>
> For my own reference, I'd like to know exactly how adding mod_gz in
> the tree will impact the few folks "working" on stabilizing the
> server (other than as a distraction on this list - which this should
> have been a easy yes vote last weekend). It's a module. No one has
> to enable it if they don't want to. It has zero impact on the rest
> of the server (due to our architecture). It implements something
> outlined in RFC 2616 that almost all browsers support today.
>
> Adding mod_gz will cause "instability" seems to be a common
> thread among the vetoers here. Please enlighten me as to how this
> is the case. -- justin
If the module is a part of the server, then it must work before the server
is production ready. You can't have a module that doesn't work in a server
that is going GA, it doesn't make sense. You will find if you read the
archives, that we have cancelled releases in the past, because a single
module did not work correctly. Anytime you put something into the core,
you take the very real chance of delaying the core server.
This is why I am against putting everything into the core. The core should
be as small as possible, so that an individual module doesn't hold up
releases.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0 STATUS
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Sep 06, 2001 at 02:39:18PM -0400, Bill Stoddard wrote:
> +1 on the veto :-)
>
> I am a strong +1 in favor of making this a subproject and probably rolling it into a post
> 2.0 release. The presence of mod_gz in the core now -will- impact folks who are working on
> stabilizing the server.
For my own reference, I'd like to know exactly how adding mod_gz in
the tree will impact the few folks "working" on stabilizing the
server (other than as a distraction on this list - which this should
have been a easy yes vote last weekend). It's a module. No one has
to enable it if they don't want to. It has zero impact on the rest
of the server (due to our architecture). It implements something
outlined in RFC 2616 that almost all browsers support today.
Adding mod_gz will cause "instability" seems to be a common
thread among the vetoers here. Please enlighten me as to how this
is the case. -- justin
Re: cvs commit: httpd-2.0 STATUS
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 06 September 2001 12:01, Bill Stoddard wrote:
> > Bill Stoddard wrote:
> > > I am a strong +1 in favor of making this a subproject and probably
> > > rolling it into a
>
> post
>
> > > 2.0 release. The presence of mod_gz in the core now -will- impact folks
> > > who are
>
> working on
>
> > > stabilizing the server.
> >
> > What about putting it in the experimental directory? This way it's
> > available for the adventurous, but will not impact on the people who are
> > after stability.
>
> That works for me as long as we do not attempt to integrate it into the
> build environment until after 2.0 goes out.
The experimentals directory should not be a dumping ground for every
module that doesn't get into the core.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0 STATUS
Posted by Bill Stoddard <bi...@wstoddard.com>.
> Bill Stoddard wrote:
>
> > I am a strong +1 in favor of making this a subproject and probably rolling it into a
post
> > 2.0 release. The presence of mod_gz in the core now -will- impact folks who are
working on
> > stabilizing the server.
>
> What about putting it in the experimental directory? This way it's
> available for the adventurous, but will not impact on the people who are
> after stability.
>
That works for me as long as we do not attempt to integrate it into the build environment
until after 2.0 goes out.
Bill
Re: cvs commit: httpd-2.0 STATUS
Posted by Graham Leggett <mi...@sharp.fm>.
Bill Stoddard wrote:
> I am a strong +1 in favor of making this a subproject and probably rolling it into a post
> 2.0 release. The presence of mod_gz in the core now -will- impact folks who are working on
> stabilizing the server.
What about putting it in the experimental directory? This way it's
available for the adventurous, but will not impact on the people who are
after stability.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: cvs commit: httpd-2.0 STATUS
Posted by Bill Stoddard <bi...@wstoddard.com>.
+1 on the veto :-)
I am a strong +1 in favor of making this a subproject and probably rolling it into a post
2.0 release. The presence of mod_gz in the core now -will- impact folks who are working on
stabilizing the server.
Bill
> * On 2001-09-06 at 11:51,
> rbb@apache.org <rb...@apache.org> excited the electrons to say:
> >
> > I am veto'ing this, for now at least. I will support making mod_gz
> > a separate sub-project of httpd, and possibly rolling it into a later
> > release of 2.0, but now is not the time to do this.
>
> Vetos need a valid technical justification, not just an opinion..
> --
> #ken P-)}
>
> Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
> Author, developer, opinionist http://Apache-Server.Com/
>
> "All right everyone! Step away from the glowing hamburger!"
>