On Jun 4, 2010, at 1:23 PM, Graham Leggett wrote: > "CTR is fine for all normal fixes. RTC is always preferred for major code > refactorings." > > I ask you this: What constitutes "a modest new feature"? It's not a fix. It's > not a major code refactoring. But modest new features have been strongly > objected to by a small group of people on this list who insisted it was a > clear cut case of "should have reviewed first", on a branch that is CTR. > > I have absolutely no objection whatsoever to the need for review of a major > code refactoring. I have absolutely no objection whatsoever to those who > express the opinion that a piece of committed code is inappropriate or > unnecessary. But we've reached the point where people want anything that > isn't any more than a fix to be reviewed first *before* commit as a matter of > procedure, and this wooly grey area cannot continue.
Please see http://httpd.apache.org/dev/guidelines.html under the heading "When to Commit a Change". Ideas must be review-then-commit; patches can be commit-then-review. With a commit-then-review process, we trust that the developer doing the commit has a high degree of confidence in the change. Doubtful changes, new features, and large-scale overhauls need to be discussed before being committed to a repository. Any change that affects the semantics of arguments to configurable directives, significantly adds to the runtime size of the program, or changes the semantics of an existing API function must receive consensus approval on the mailing list before being committed. ....Roy
