Update an old vote (actually, the bug was two issues).

  Call a vote a vote, and trim up STATUS a bit.  R-T-C on branches/httpd-2.0
  was decided, revisited at AC2004, and modified a bit for lazy concensus
  of platform maintainance changes, based on list discussion.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x@151466 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/STATUS b/STATUS
index 836d1699f857ea95260be3e3cfa982886a0bdab1..0f9e290bec95ae86ac086b62d60c96585ae7ee2b 100644 (file)
--- a/STATUS
+++ b/STATUS
@@ -119,10 +119,11 @@ PATCHES TO BACKPORT FROM TRUNK:
        PR: 32529
        +1: jorton
 
-    *) win32: Handle PATH_INFO as opaque byte-wise data for cgi invocation,
-              as handled for other variables originally fixed in bug 9223.
-              PR: 32730 Submitted by: Richard Donkin <rd9 donkin.org>
-       svn rev 124556
+    *) win32: Handle PATH_INFO -and- PATH_TRANSLATED as opaque byte-wise 
+       data for cgi invocation, as handled for other variables originally 
+       fixed in bug 9223, within modules/arch/win32/mod_win32.c.
+       PR: 32730 Submitted by: Richard Donkin <rd9 donkin.org>
+       svn rev 124556 + 151464
        +1: wrowe
 
     *) several changes to improve logging of connection-oriented errors, including
@@ -382,84 +383,6 @@ CURRENT VOTES:
       +1: bnicholes, wrowe
       +0: minfrin (wait till the last cache bugs are ironed out)
 
-    * Develop in Review-Then-Commit or Commit-Then-Review mode 
-      on APACHE_2_0_BRANCH (no vetoes, this is a straight vote.)
-       R-T-C:   trawick, wrowe, jerenkrantz, stoddard, rederpj, striker, nd,
-                gregames(lazy consensus OK for mainline), jwoolley
-       Abstain: 
-       C-T-R:   BrianP, aaron, jim, gstein, bnicholes, minfrin
-       
-       gstein: we have an open branch, so there is an easy release
-               valve for feature and API changes. we trust developers
-               to put their changes in the right place. if they
-               *don't*, that is what the -T-R is all about, and why we
-               have source control.
-               
-               yes, the branch should be "bug fix only" or other
-               voted-upon feature changes, but we already have
-               guidelines for all that.
-
-                 http://httpd.apache.org/dev/guidelines.html
-               
-               see the section titled "Product Changes" and the
-               following paragraph which states:
-
-               "... All product changes to a prior-branch (old
-               version) repository require consensus before the change
-               is committed."
-
-               And under "When to Commit a Change", first line:
-               
-               "Ideas must be review-then-commit; patches can be
-               commit-then-review."
-
-               The problem here is that R-T-C expresses a fundamental
-               DISTRUST of your peers. We had problems stabilizing the
-               code simply because there are numerous interests in the
-               codebase, and those are not fully compatible. With the
-               branch, we have partitioned the interest: bug fix vs
-               new features. But developers *know* when a bug fix
-               should be applied or should not. There is no reason to
-               tell a developer they are wrong, and their basic
-               understanding of what is broken and what needs to be
-               fixed is subject to peer review. Once you have a bug
-               fix in hand, it isn't rocket science. And, always,
-               there is the option to pull a fix back out if a
-               developer goofs. We all goof, but there is no sense in
-               ASSUMING that incorrect behavior is the norm.
-
-               If a develop consistently causes problems, then we have
-               ways of dealing with that. But at the moment, this
-               isn't the case, and it does not foster a healthy
-               environment to apply that label to ALL developers.
-               R-T-C is fundamentally "you're guilty of bad behavior,
-               with no way to prove innocence. all your actions are
-               hereby monitored."
-               
-               Why did I wait so long to issue this commentary? Simply
-               because I disagreed with it at such a fundamental level
-               that I didn't want to deal with it. Also, that I
-               *wasn't* going to deal with it when I had changes to
-               commit. But now we're seeing this stupid R-T-C hammer
-               being used to smack developers over the head. That is
-               inappropriate when the bug fixes they are committing to
-               the branch are entirely reasonable and appropriate. The
-               hammer simply should not exist.
-               
-               Yes, I'm ranting, and hey, I'm even sober. :-) R-T-C is
-               Badness. If I could veto the policy, I would. If I can
-               ignore it, I will. For years, this group was built on
-               the notion of peer respect and trust. R-T-C destroys
-               that, and makes the environment less cozy and less
-               inviting. Our polcies and procedures were designed to
-               operate successfully in a C-T-R environment; there is
-               no need for such a draconian policy.
-
-               Bleh.
-
-       minfrin: I see no point in adding any bureaucracy between a bug
-                and its fix.
-
     * httpd-std.conf and friends;
 
       a) httpd-std.conf should be tailored by install (from src or