Date: Tue, 28 Dec 1999 00:06:08 -0800 (PST)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
Subject: Re: 1.3.10 release... postponed
In-Reply-To: <19991228084354.A59619@engelschall.com>
Message-ID: <Pine.LNX.4.21.9912272353150.13504-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Tue, 28 Dec 1999, Ralf S. Engelschall wrote:

> even if the 2.0-enthusiasts like you hate me for this. And please don't
> complain that I should instead of working on 1.3 direct my efforts to
> 2.0 to reduce the time it needs to make 2.0 stable. We still need 1.3
> _NOW_, so I don't think it is unreasonable to still put efforts into
> this series...

if you wait and come in at the end of the 2.0 development cycle you'll
meet resistance, just like you're meeting resistance now.  it's early
in the dev cycle that large changes such as ipv6 and eapi should go in,
not late.

if we let you put this into 1.3 then we put ourselves in the position
of requiring ipv6 and eapi in 2.0 before we can release 2.0.

sorry, if this comes to a vote i'm voting -1 on these enhancements in
1.3 without a plan, a volunteer, and maybe even a preliminary patch
for getting them into 2.0.

sure i suppose we could just ignore these for 2.0 and agree that 2.0
just doesn't do everything 1.3 does.  but then what?  we get into 2.1
development and you release a new patch set for 2.0 because you don't
want to touch the dev branch (same logic you're using now)?

maybe i'm missing something though :)  if you guys tell me that 2.0
has this functionality already then i don't really care about it going
into 1.3.  i haven't paid close enough attention, sorry.  all i remember
is that ben laurie and i looked at EAPI and KEAPI(?) and didn't like
the performance implications of either, and so he implemented something
else which has better performance.  so maybe we're not so far off.

Dean