From: William A. Rowe Jr Date: Sat, 5 Feb 2005 01:58:31 +0000 (+0000) Subject: Update an old vote (actually, the bug was two issues). X-Git-Tag: 2.0.54~73 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=a388e5ce7b6da5ece816d110ce6e9af5742ed796;p=thirdparty%2Fapache%2Fhttpd.git 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 836d1699f85..0f9e290bec9 100644 --- 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 - 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 + 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