Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <6.2.1.2.2.20050502180858.060e3bc0@pop3.rowe-clan.net>
Date: Mon, 02 May 2005 18:17:02 -0500
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: [PROPOSAL] Branch 2.1.x on May 13
Cc: dev@httpd.apache.org
In-Reply-To: <4276A02C.9030306@force-elite.com>
References: <200505022128.j42LSgV27523@devsys.jaguNET.com>
 <4276A02C.9030306@force-elite.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:48 PM 5/2/2005, Paul Querna wrote:

>Personally, I have held off on starting refactors of code, because I do
>not want to be detrimental to the ability to make a 2.2 Branch.
>
>I would like to investigate making more parts of httpd async, in
>conjunction with the Event MPM.  I would also like to redo some of the
>configuration system -- but I have avoided working on these, because of
>my personal belief that 2.1-dev has enough for a new GA branch.

First - let me say I TOTALLY agree with your concept for more
async features and design!!!

Second - there is no way that disconnected/async events that can
jump threads will ever fit into httpd-2.  That quantum leap must
be httpd-3 because it breaks the assumptions and gross hacks of
many module authors.  Even if we 1. never leap threads between
translate_name and finalize_request, therefore 2. restrict all
async to the reception of the request packet; there will still be
affected modules, mod_sspi and user tracking apps that span
pipelines - which don't expect data to jump threads on the connection
layer.

>I think there is wide agreement that /trunk/ should always be open for
>commits.  I don't imagine that my personal development ideas match
>everyone, and they are not my only reason for wanting a 2.1.x branch.

Absolute rule, trunk/ should always build as well.  If it can't build,
it should be reparable within a very short window.  Hopefully not by
the committer, but more likely, by platform maintainers 'catching up'.

That said, I'm strongly -1 on dropping such radical changes directly
into trunk/.  There is no way code changes on this scale are ever CTR.
We have SVN, so creating sandboxes/experimental/proof-of-concept
branches are trivial :)

This was true of every major refactoring of Apache since Shambala.
Create a sandbox today to start experimenting with async models.

>This has somewhat turned into the real question, What are the show
>stoppers for a 2.2 GA Branch?
>
>If you believe an issue is a show stopper for a GA Branch, please add it
>to the STATUS File.

So to amend your original proposal; on May 13;

  * tagging an alpha candidate
  * identifying all showstoppers to GA

and if that list is short enough, we will be able to read how long
the window from 2.1-dev to 2.2 GA actually is, and if we are fitting
into something that resembles a one month timeframe.

Bill