Commit ff73837e authored by William A. Rowe Jr's avatar William A. Rowe Jr
Browse files 

  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
parent 783d958f

STATUS

+5 −82
Original line number Diff line number Diff line
@@ -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.

    *) 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

       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