Feature freeze?

[Jim Jagielski <ji...@jaguNET.com>]

Some may recall that awhile ago the status module included a field
that indicated how long it took for Apache to handle the request.
This was dropped since the method used had only second granularity.
Right now I have a patch that adds this back using gettimeofday
(and even times)... But this is definately a Feature and not a Fix.

Are we in Feature Freeze? I think we should be, but....
-- 
====================================================================
      Jim Jagielski            |       jaguNET Access Services
     jim@jaguNET.com           |       http://www.jaguNET.com/
                  "Not the Craw... the CRAW!"

Re: Feature freeze?

[Rob Hartill <ro...@imdb.com>]

On Thu, 6 Feb 1997, Alexei Kosut wrote:

> We can do 2.0 in the same amount of time as we can do 1.3 - with or
> without the RST code, probably, though I'd rather use it if we
> can. The Apache Group cannot do things quickly.

I thought we agreed to try not to discuss 2.0 until 1.2 was out the door.

_______________________________________________________________________
Rob Hartill.       Internet Movie Database Ltd.    http://www.imdb.com/
CGI ? how quaint.

Re: Feature freeze?

[Dean Gaudet <dg...@arctic.org>]

I think a config syntax redesign is in order.  But if we rewrite that too
then what's left to call it apache?  :)

I am still not against a 1.3 -- but a 1.3 only if someone wants to step up
and be release manager and let the rest of the group go off and start 2.0.
Essentially a 1.3 that includes whatever contrib we get, and that's about
it.  Something like INN 1.4unoff1 through INN 1.4unoff4. 

Dean

On Thu, 6 Feb 1997, Alexei Kosut wrote:

> On Thu, 6 Feb 1997, Marc Slemko wrote:
> 
> > Things are being held up here by "one more release" before...
> 
> Yes. Apache 1.2 was supposed to be done by August.
> 
> > I'm sure people who have been around longer than I have can tell great
> > stories about what was to be the last release before 2.0.
> 
> 1.1.0.
> 
> We can do 2.0 in the same amount of time as we can do 1.3 - with or
> without the RST code, probably, though I'd rather use it if we
> can. The Apache Group cannot do things quickly.
> 
> > What really has to be figured out is what do we have for a code base to
> > start with?  Can RST's implementation be used?  If so, should it?  If not,
> > who will be writing the alternative?  The base of it essentially has to be
> > done by one or two people I think.  
> 
> If RST's cannot be used, or even if it can, we need to divide the
> "major enhancements" up, and probably assign someone to write the bulk
> of the code and oversee it. We have at least these three:
> 
> 1. Threading. RST's code has this. Otherwise I nominate Ben. He seems
>    to be the most well-versed in threading and that sort of thing here.
> 2. I/O (filtering, stacked IO, mmaping files, whatever). RST's codes
>    have done this, with sfio or bsdio. Anyone want to volunteer to
>    coordinate this?
> 3. API enhancements. This includes additional phases, and new
>    functions to go along with the new I/O stuff. RST's code didn't
>    really have this, so we'll have to write it anyway. I'd like to
>    manage this part of it, actually, if no one minds.
> 
> At any rate, I think 1.2 has at least one or two more betas left in
> it. 1.2b6 and 1.2b7 have/will have a lot of minor changes in them that
> should be tested. 1.2b7 may end up being the release candidate, but we
> shouldn't advertiste it as such.
> 
> -- 
> ________________________________________________________________________
> Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
> URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/
> 
> 

Re: Feature freeze?

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

On Thu, 6 Feb 1997, Marc Slemko wrote:

> Things are being held up here by "one more release" before...

Yes. Apache 1.2 was supposed to be done by August.

> I'm sure people who have been around longer than I have can tell great
> stories about what was to be the last release before 2.0.

1.1.0.

We can do 2.0 in the same amount of time as we can do 1.3 - with or
without the RST code, probably, though I'd rather use it if we
can. The Apache Group cannot do things quickly.

> What really has to be figured out is what do we have for a code base to
> start with?  Can RST's implementation be used?  If so, should it?  If not,
> who will be writing the alternative?  The base of it essentially has to be
> done by one or two people I think.  

If RST's cannot be used, or even if it can, we need to divide the
"major enhancements" up, and probably assign someone to write the bulk
of the code and oversee it. We have at least these three:

1. Threading. RST's code has this. Otherwise I nominate Ben. He seems
   to be the most well-versed in threading and that sort of thing here.
2. I/O (filtering, stacked IO, mmaping files, whatever). RST's codes
   have done this, with sfio or bsdio. Anyone want to volunteer to
   coordinate this?
3. API enhancements. This includes additional phases, and new
   functions to go along with the new I/O stuff. RST's code didn't
   really have this, so we'll have to write it anyway. I'd like to
   manage this part of it, actually, if no one minds.

At any rate, I think 1.2 has at least one or two more betas left in
it. 1.2b6 and 1.2b7 have/will have a lot of minor changes in them that
should be tested. 1.2b7 may end up being the release candidate, but we
shouldn't advertiste it as such.

-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/

Re: Feature freeze?

[Marc Slemko <ma...@znep.com>]

On Thu, 6 Feb 1997, Lou D. Langholtz wrote:

> Lastly, I'm definately for seeing 1.2 done asap too. Then a QUICK 1.3
> with just the minor additional features suggested so far (anything that
> required mods to three files or less) gets a +1 vote from me. Seems like
> in the future a few modules (albiet some of the most useful like
> mod_rewrite and mod_sucgi) need to be seperated back out again from the
> distribution though so that future releases aren't as interdependent.

Things are being held up here by "one more release" before...

I'm sure people who have been around longer than I have can tell great
stories about what was to be the last release before 2.0.

IMHO, after 1.2 comes out we need to plan on no more 1.x releases except
for expected bugfix releases.  Branching the tree at that point would be a
good thing, and would at least let the work on 2.0 get started.  If we
have to come back to 1.x, so be it, but...

What really has to be figured out is what do we have for a code base to
start with?  Can RST's implementation be used?  If so, should it?  If not,
who will be writing the alternative?  The base of it essentially has to be
done by one or two people I think.  

Releasing 1.2 will not give any room to go ahead unless we know exactly
where we are going.  Perhaps everyone else does, but I don't. 

Re: Feature freeze?

["Lou D. Langholtz" <ld...@cs.utah.edu>]

Jim Jagielski wrote:
> 
> Some may recall that awhile ago the status module included a field
> that indicated how long it took for Apache to handle the request.
> This was dropped since the method used had only second granularity.
> Right now I have a patch that adds this back using gettimeofday
> (and even times)... But this is definately a Feature and not a Fix.
> . . .

I'd love to see your code anyway. I just recently switcehd the
scoreboard.h related code to use gettimeofday() timeval's instead of
time() time_t's to get accurate breakdowns on how busy time is spent on
average and am considering switching to getrusage() instead of times()
as well. If you already got all this functionality working though... :-)

As somewhat of a sidenote, getrusage() seems to be more standard (as far
as portability is concerned) than times() so switching seems inevitable
especially since you get more info out of getrusage() ;-)

I cc'd everyone else just to keep the version 2 thoughts flowing and
stuff logged.

Lastly, I'm definately for seeing 1.2 done asap too. Then a QUICK 1.3
with just the minor additional features suggested so far (anything that
required mods to three files or less) gets a +1 vote from me. Seems like
in the future a few modules (albiet some of the most useful like
mod_rewrite and mod_sucgi) need to be seperated back out again from the
distribution though so that future releases aren't as interdependent.

Re: Feature freeze?

[Rob Hartill <ro...@imdb.com>]

On Mon, 3 Feb 1997, Jim Jagielski wrote:

> Some may recall that awhile ago the status module included a field
> that indicated how long it took for Apache to handle the request.
> This was dropped since the method used had only second granularity.
> Right now I have a patch that adds this back using gettimeofday
> (and even times)... But this is definately a Feature and not a Fix.

We have a user patch for this somewhere.

> Are we in Feature Freeze?

I hope so.

> I think we should be, but....