httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: 1.2.6
Date Mon, 23 Feb 1998 02:03:48 GMT
If you guys don't want to think about 1.2 that is totally fine.
I probably won't think about anything other than protocol errors after
1.2.6.  1.2 is a reference HTTP/1.1 implementation, it is in our interest
to ensure that it is a faithful implementation.

I really don't understand what your first paragraph means: 

On Sun, 22 Feb 1998, Jim Jagielski wrote:

> I think that after a point in time, we should spend our time
> focusing on the newer version and not adding things to the older
> one to make it closer to the newer yet unreleased one (unless
> the bugs are serious or security related).

What specifically are you saying I've done in 1.2.6 that is wasted
duplication of 1.3 effort?  And how do you think I could have helped
1.3 development efforts more with that time?  (I refuse to work on
NT at the moment because I simply do not have the mental bandwidth to
deal with that plus my regular apache work, and my real job.)

> At this point in time, I think the best use of our limited efforts
> would be in getting 1.3 out and not tuning 1.2.x.

"limited" yes, so then why aren't we asking for specific 1.2 help from our
vast pool of users?  Why do we always assume that we're the only ones
qualified to make decisions about apache?

If you or Randy or whoever else don't want to think about 1.2 then don't,
I didn't say everyone had to subscribe to the proposed 1.2 testers
mailing list.  I'm happy spending a bit of my time on it, specifically
because I don't think that 1.3 will be out any time soon *unless* we
divorce the idea that NT and unix must be kept in synch.  (I point out
commercial products such as navigator, and rvplayer which do not keep in
synch across platforms, and free products like glibc which drop platform
compatibility when they can't muster enough testers to maintain it.)

Perhaps folks familiar with the freebsd -stable versus -current
development can comment.  I'm more familiar with linux 2.0.x versus 2.1.x

    2.0.x: a smaller group of developers maintain the stable tree, they're
	called the Linux Maintenance Project.  They make pre-releases
	available for testing periodically, and based on the results of that
	they're able to make very stable releases.  Amongst the folks doing
	this work are the folks who absolutely need a stable kernel with
	the current feature set.  Testing proceeds at a relatively rapid
	pace because of the widespread availability of pre-releases.

    2.1.x: a much larger group of developers patch the experiment tree.
	Occasionally there are pre-releases, but usually Linus just
	releases whatever he has when he thinks there's sufficient
	development in it.  Sometimes the current version is completely
	broken, usually it isn't... if it's broken then there's usually
	patches to fix it within an hour or two.  Testing proceeds at a
	very rapid pace because of widespread availability of frequent

Apache testing proceeds at a very lethargic pace because we insist that
every time we mail it be a totally golden release.
That's fine, but we'd gain a lot more by having a list of folks willing
to test releases before we call them golden.  Almost every case where
we've had to ditch 1.x.y and roll 1.x.(y+1) immediately would have been
caught by such a list.

We have almost no test suite (Brian, you wrote an imap test that should
be checked into the source tree) so we have to rely on our users to
test things for us.  Why are we making it so hard on ourselves and on
our users to test things?


View raw message