You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2001/01/11 21:59:32 UTC
Beta.
I am sick of Apache 2.0. That doesn't mean that I am ready to stop
working on it, I'm not. I love this piece of software, and I am likely to
be working on Apache 2.0 for it's full life cycle. It does mean that I am
ready to move from Apache 2.0 alpha to Apache 2.0 beta to Apache 2.0.
I believe that this means that we have to make a concerted effort to get
this release to a beta version soon. I would like to ask that we go into
feature freeze now. This means we will fix bugs, but that is it until we
hit beta.
Now, if after we hit beta, we want to add new features, that is a decision
we can make. Personally, I don't believe we should. The Apache group
entered a feature freeze before Apache 1.2 and 1.3. This is obvious by
looking at the bug reports that were suspended with the message: "We are
too far into this development cycle to add a new feature, we will
reconsider for X.X".
When I say fix bugs, by the way, I consider anything in the STATUS
file right now a bug. I do not believe we should add everything to the
STATUS file tonight. If it isn't already in the STATUS file, it isn't a
known bug. We may find more bugs, but that is very different from saying
that there is a new feature we want to add, so it is now a bug.
Thoughts, comments?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Beta.
Posted by Greg Ames <gr...@raleigh.ibm.com>.
rbb@covalent.net wrote:
>
>
> I believe that this means that we have to make a concerted effort to get
> this release to a beta version soon. I would like to ask that we go into
> feature freeze now. This means we will fix bugs, but that is it until we
> hit beta.
>
++1. _exactly_ what we need at this point
Greg
Re: Beta.
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> I believe that this means that we have to make a concerted effort to get
> this release to a beta version soon. I would like to ask that we go into
> feature freeze now. This means we will fix bugs, but that is it until we
> hit beta.
> Thoughts, comments?
sounds good... I'm looking forward to a several day stretch when I
don't have to figure out why apache no longer builds on one or more
platforms :)
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: Beta.
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> I believe that this means that we have to make a concerted effort to get
> this release to a beta version soon. I would like to ask that we go into
> feature freeze now. This means we will fix bugs, but that is it until we
> hit beta.
>
+1
Re: Beta.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: <rb...@covalent.net>
Sent: Thursday, January 11, 2001 2:59 PM
> I believe that this means that we have to make a concerted effort to get
> this release to a beta version soon. I would like to ask that we go into
> feature freeze now. This means we will fix bugs, but that is it until we
> hit beta.
+1
API changes (was Re: Beta.)
Posted by dean gaudet <dg...@arctic.org>.
On Mon, 15 Jan 2001, Bill Stoddard wrote:
> > does feature freeze mean no API changes to fix the problems i pointed out
> > with code that uses rprintf/rputs? i'd be -1 on beta in that case.
>
> I agree. I am +1 on a feature freeze. Fixing problems with the API
> (regardless of how much code is impacted) is okay.
ok, please indicate in the beta announcement that the API is *not* frozen
and that module authors may want to wait, or be prepared to accomodate API
changes.
btw, there's some other API changes which should probably happen in terms
of cleanup. here's a few from that old mess, server/util.c:
ap_chdir_file() is not portable across MPMs because CWD is a per-process
thing, not a threaded thing. the function should be eliminated.
mod_include is the main thing impacted by this.
ap_escape_shell_cmd() should probably be in APR rather than httpd.
initgroups() should be in APR ... maybe, dunno. does 2.0 even work on
unixes which don't have initgroups(3)?
ap_uname2id(), ap_gname2id() ... more unixisms.
-dean
Re: Beta.
Posted by Bill Stoddard <bi...@wstoddard.com>.
> does feature freeze mean no API changes to fix the problems i pointed out
> with code that uses rprintf/rputs? i'd be -1 on beta in that case.
I agree. I am +1 on a feature freeze. Fixing problems with the API
(regardless of how much code is impacted) is okay.
Bill
Re: Beta.
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> > > Dean, we know the API's don't mesh well. The problem is that when we were
> > > implementing the buckets, we were told we couldn't change the ap_r*
> > > function's APIs.
> >
> > Argh, you keep saying this. It is the semantics of the ap_r* (or ap_b*) calls that needs to be
> > maintained (more or less), not the exact syntax.
>
> Then there was a HUGE communication break-down, because that is not what
> was said at the filter meeting.
I think there were exactly two people at that meeting who grok'ed everything discussed (and I was
not one of them :-).
> What was said at the filter meeting, was
> that the API's couldn't change, not that the semantics couldn't change. I
> would have written those functions completely differently if I could
> remove the request_rec and pass in a bucket_brigade in it's place.
Okay. We all know a lot more than we did 6 or 8 months ago. Clearly what we have now is not
sufficient and I think you and Dean are on the right track.
Bill
Re: Beta.
Posted by rb...@covalent.net.
> > Dean, we know the API's don't mesh well. The problem is that when we were
> > implementing the buckets, we were told we couldn't change the ap_r*
> > function's APIs.
>
> Argh, you keep saying this. It is the semantics of the ap_r* (or ap_b*) calls that needs to be
> maintained (more or less), not the exact syntax.
Then there was a HUGE communication break-down, because that is not what
was said at the filter meeting. What was said at the filter meeting, was
that the API's couldn't change, not that the semantics couldn't change. I
would have written those functions completely differently if I could
remove the request_rec and pass in a bucket_brigade in it's place.
However, what was said, was that existing handlers needed to continue to
compile and run, so we couldn't require that a handler call
ap_pass_brigade, which is what would be required to do this right. If I
can force handler writers to call ap_pass_brigade, then this all becomes
simplistic to solve.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Beta.
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> Dean, we know the API's don't mesh well. The problem is that when we were
> implementing the buckets, we were told we couldn't change the ap_r*
> function's APIs.
Argh, you keep saying this. It is the semantics of the ap_r* (or ap_b*) calls that needs to be
maintained (more or less), not the exact syntax.
Bill
Re: Beta.
Posted by rb...@covalent.net.
> does feature freeze mean no API changes to fix the problems i pointed out
> with code that uses rprintf/rputs? i'd be -1 on beta in that case.
feature freeze means no more features before the beta. Afterwards, we can
work on this again.
> i know there's been some responses from folks on that topic, but nothing
> looks like anyone has a final answer. i'm not convinced that the
> performance problems can be solved given the current API. as i mentioned
> a long long time ago, this is an API i've worked with on another project,
> and i ended up removing it to eliminate the performance problems that you
> guys are now experiencing.
Dean, we know the API's don't mesh well. The problem is that when we were
implementing the buckets, we were told we couldn't change the ap_r*
function's APIs. Those two things just don't work together. Either the
buckets API's need to change, or the ap_r* functions need to change.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Beta.
Posted by dean gaudet <dg...@arctic.org>.
does feature freeze mean no API changes to fix the problems i pointed out
with code that uses rprintf/rputs? i'd be -1 on beta in that case.
i know there's been some responses from folks on that topic, but nothing
looks like anyone has a final answer. i'm not convinced that the
performance problems can be solved given the current API. as i mentioned
a long long time ago, this is an API i've worked with on another project,
and i ended up removing it to eliminate the performance problems that you
guys are now experiencing.
-dean
On Thu, 11 Jan 2001 rbb@covalent.net wrote:
>
> I am sick of Apache 2.0. That doesn't mean that I am ready to stop
> working on it, I'm not. I love this piece of software, and I am likely to
> be working on Apache 2.0 for it's full life cycle. It does mean that I am
> ready to move from Apache 2.0 alpha to Apache 2.0 beta to Apache 2.0.
>
> I believe that this means that we have to make a concerted effort to get
> this release to a beta version soon. I would like to ask that we go into
> feature freeze now. This means we will fix bugs, but that is it until we
> hit beta.
>
> Now, if after we hit beta, we want to add new features, that is a decision
> we can make. Personally, I don't believe we should. The Apache group
> entered a feature freeze before Apache 1.2 and 1.3. This is obvious by
> looking at the bug reports that were suspended with the message: "We are
> too far into this development cycle to add a new feature, we will
> reconsider for X.X".
>
> When I say fix bugs, by the way, I consider anything in the STATUS
> file right now a bug. I do not believe we should add everything to the
> STATUS file tonight. If it isn't already in the STATUS file, it isn't a
> known bug. We may find more bugs, but that is very different from saying
> that there is a new feature we want to add, so it is now a bug.
>
> Thoughts, comments?
>
> Ryan
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
>
>
>
>