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