Re: [STATUS] (httpd-2.1) Wed Dec 8 23:45:16 EST 2004

2004-12-08 Thread Justin Erenkrantz
--On Wednesday, December 8, 2004 11:45 PM -0500 Rodent of Unusual Size 
<[EMAIL PROTECTED]> wrote:

APACHE 2.1 STATUS:  -*-text-*-
Last modified at [$Date: 2004/11/06 08:28:24 $]
Ken: FWIW, httpd has switched to Subversion (and APR has too).  Is it possible 
to get your scripts updated?  Thanks!  -- justin


[STATUS] (httpd-2.1) Wed Dec 8 23:45:16 EST 2004

2004-12-08 Thread Rodent of Unusual Size
APACHE 2.1 STATUS:  -*-text-*-
Last modified at [$Date: 2004/11/06 08:28:24 $]

Release [NOTE that only Alpha/Beta releases occur in 2.1 development]:

2.1.1   : Proposed roll on 11/14/2004 (around/after Hackathon).
  Justin volunteers as RM.
2.1.0   : in development

Please consult the following STATUS files for information
on related projects:

* srclib/apr/STATUS
* srclib/apr-util/STATUS
* docs/STATUS

Contributors looking for a mission:

* Just do an egrep on "TODO" or "XXX" in the source.

* Review the "PatchAvailable" bugs in the bug database.
  Append a comment saying "Reviewed and tested".

* Open bugs in the bug database.

CURRENT RELEASE NOTES:

* When the CVS->SVN is done, there's a bogus avendor branch that should be
  removed from most files.  The branch was created 4/27/2004.  It's safest
  (and easiest) for now just to leave it in there; the MAIN branch and the
  APACHE_2_0_BRANCH are untouched and unharmed.  --jwoolley

RELEASE SHOWSTOPPERS:

* Convert httpd-2.x to Subversion.  Yes, we've voted on this a billion
  times on [EMAIL PROTECTED], but let's make this one official.  Majority 
rules.

  +1: jerenkrantz, pquerna

* Handling of non-trailing / config by non-default handler is broken
  http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105451701628081&w=2
  jerenkrantz asks: Why should this block a release?

* the edge connection filter cannot be removed 
  http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=2
  jerenkrantz asks: Why should this block a release?

CURRENT VOTES:

* Promote mod_cache from experimental to non-experimental
  status (keep issues noted below in EXPERIMENTAL MODULES as
  items to be addressed as a supported module).
  +1: jerenkrantz, pquerna
  +0: jim, bnicholes
  -1: stoddard
  There are a couple of problems that need to be resolved
  before this module is moved out of experimental. 
  1) We need to at least review and comment on the RFC violations
  2) Resolve issue of how to cache page fragements (or perhaps -if- we
  want to cache page fragements). Today, mod_cache/mod_mem_cache
  will cache #include 'virtual' requests (but not #include 'file' 
  requests). This was accomplished by making CACHE_IN a
  CONTENT_SET-1 filter to force it to run before the SUBREQ_CORE
  filter.  But now responses cannot be cached that include the
  effects of having been run through CONTENT_SET filters
  (mod_deflate, mod_expires, etc).  We could rerun all the
  CONTENT_SET filters on the cached response, but this will not
  work in all cases. For example, mod_expires relies on installing
  the EXPIRATION filter during fixups. Contents served out of
  mod_cache (out of the quick_handler) bypass -all- the request
  line server hooks (Ryan really hated this. It is great for
  performance, but bad because of the complications listed above).

  jerenkrantz: I think it's time.  We've done a *lot* of work to it, and
   we think most of the blatant RFC violations are now gone.
   mod_cache just belongs in cache/.  There may still be bugs,
   but not likely to be major ones.  Note that I'm not moving
   *anything* until we switch to SVN.

* httpd-std.conf and friends

  a) httpd-std.conf should be tailored by install (from src or
 binbuild) even if user has existing httpd.conf
 +1:   trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd,
   erikabele
   wrowe - prefer httpd.default.conf to avoid ambiguity with cvs

  b) tailored httpd-std.conf should be copied by install to
 sysconfdir/examples
 -0:   striker

  c) tailored httpd-std.conf should be installed to
 sysconfdir/examples or manualdir/exampleconf/
 +1:   slive, trawick, Ken, nd (prefer the latter), erikabele

  d) Installing a set of default config files when upgrading a server
 doesn't make ANY sense at all.
 +1:   ianh - medium/big sites don't use 'standard config' anyway, as it
  usually needs major customizations
 -1:   Ken, wrowe, jwoolley, jim, nd, erikabele
   wrowe - diff is wonderful when comparing old/new default configs,
   even for customized sites that ianh mentions
   jim - ... assuming that the default configs have been updated
 with the required inline docs to explain the
 changes

* If the parent process dies, should the remaining child processes
  "gracefully" self-terminate. Or maybe we should make it a runtime
  option, or have a concept of 2 parent processes (one being a 
  "hot spare").
  See: Message-ID: <[EMAIL PROTECTED]>

  Self-destruct: Ken, Mart