httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: What's next for 2.2 and 2.3/trunk?
Date Sun, 06 Jun 2010 18:48:38 GMT
On Saturday 05 June 2010, Roy T. Fielding wrote:
> 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
> 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.

I very much agree with this policy. Usually it works quite well.

But having no one review the contributions from a new (or even a not 
so new) contributor can be very demotivating. I think all commiters 
should look for such situations and suggest/implement remedies (e.g. 
additional branches, as Jim suggested, or by commenting on the ideas 
even if one has too little time to review the patches). Also, the 
problem is less likely to occur when there are more committers. So, 
more committers should be added whenever possible, and with as little 
delay as possible.


PS: The above page could use a clarification what the "Apache group" 
actually is. The commiters or only the PMC?

View raw message