httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: random questions...
Date Tue, 06 Aug 1996 03:16:29 GMT

Jumping back into the fray after 5 days of not reading Apache mail - caveat

On 5 Aug 1996, Paul Richards wrote:
> Alexei Kosut <> writes:
> > 
> > On Fri, 2 Aug 1996, Randy Terbush wrote:
> > 
> > > Is anyone else feeling that this 1.2 release is a bit rushed?
> > 
> > It was designed to be rushed. *shrug* It's an interim release between 1.1
> > and 2.0.
> I'm not that enthusiastic about this 1.2 thing. We seem to be rushing
> a release out just for the sake of it because we think 2.0 will be a
> long way off. This is the wrong way to do things.

The opposite.  We are keeping our objectives for 1.2 limited (a term, and a
mindset, I would prefer to see used instead of "rushing") precisely *so* 2.0
won't be a long ways off.

> We should decide on a feature set for 1.2 and then it takes as long as
> it takes to get 1.2 out in good shape.

Well, we tried to do that, I did have a fairly good list at, which I asked for input on and
got some and incorporated it, but I wouldn't say we got consensus on it.  And
then people went off and decided we needed to rebuild autoconf - which I think
is a well-intentioned but misguided affair.  Please cut me some slack until I
catch up on the current status of things, but if we're talking about
reimplementing most of what autoconf can provide for us, we're silly to do that
before 2.0, in my opinion.

> As I said before, if the HTTP 1.1 changes can be put into 1.2 and
> easily be incorporated into 2.0 then we should go that route. Getting
> rst's 2.0-dev code into CVS would make that easier. We can then do a
> 1.2 release that gets us compatible with the new spec without too much
> wasted effort.
> 1.2 isn't going to be an interim release, there's too much totally new
> work being done on it. It's got to be well tested as usual and that
> always holds up development, the maxim should always be that you can't
> do quick releases, the release engineering always ends up taking as
> much time as the development does.
> The alternative would be to just get on with 2.0 and release it as a
> major new advance for Apache, a threaded 1.1 conformant server,
> release it sometime in the Autumn with a big splash. I'm beginning to
> think that we'd make more rapid progress if we went that route.

I know Rob can speak for himself, and for all I know he probably has on this,
but after talking with him on a couple of technical points it makes sense to
not work on it for another couple of weeks until he has a
protocol-independence/muxing interface he's happy with.  Those things are
difficult to change once the code has been opened to the group; in the meantime
let's make sure we've got in 1.2 all the basic elements we'd like, that we
polish it up and run it through the usual pre-release beta cycle, and then we
can start on 2.0.  

My thoughts and suggestions, as always.



View raw message