On Thu, Jun 3, 2010 at 7:51 PM, Graham Leggett <minf...@sharp.fm> wrote:
> On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote: > > It would be, but it's necessary. The ASF is a collaborative environment; >> unreviewed code should not released, even when the authors are committers. >> A major patch like this hitting svn, without previous review, makes our >> fellow committers' eyes glaze over. >> >> If there is not positive feedback from two reviewers, this code does not >> belong in trunk/. As a committer, you are *free* to create your own >> sandboxes in svn to demonstrate code changes, if that helps attract the >> necessary review. >> > > What you're describing here is review-then-commit (RTC). > > If we want trunk to be review-then-commit then we must make a decision and > make it review-then-commit. If trunk is to remain commit-then-review (CTR), > then people must be free to commit, then have people review. > > We cannot continue with this weird "limbo" situation where trunk is > officially CTR, but unofficially RTC, because you have to check first on the > list before committing anything, and you're too scared to commit anything > because you're scared you're going to offend somebody who believes they > should have been consulted first before someone commits to a CTR branch. > > The reason CTR is ideal for trunk is because the consequences of the rest > of the project being too busy to review the code, is that the code is > accepted without dispute. This produces a clear incentive to make sure that > the rest of the project reviews code. It's really easy for the rest of the > project to go "I don't care about feature X, so I'll ignore reviewing that > proposed code, I'm too busy". Under RTC, progress slows, people get fed up > waiting for other people to review, progress stops, project dies. > > Having said that, RTC is entirely appropriate for the stable branch. Here > the point is stability - we don't want progress, unless the progress is > justified through the agreement of at least 3 other people. Progress slows, > but progress doesn't stop, because the person writing the code can always > wait until trunk becomes the next stable version. > > We've been doing this like this for over a decade, and it has worked really > well. If you want the policy to be changed, argue that the policy should be > changed. But do not try and apply a pseudo-policy on top of the already > established ASF practice of CTR, it's not fair to our contributors. > +1 for the continued, and perhaps more widespread, voluntary soliciting of approval in advance for changes which add new modules or other significant new function, or make other widespread changes, or change prerequisites in a meaningful way, or have been discussed in the past without resolution (or with outright rejection), etc., etc. (We don't need an explicit laundry list, or any additional policy, to codify the practical matter that multiple developers need to be ready and willing to cope with such changes when they reach the user base). This has been done countless times by numerous people in this successful decade, in spite of, and even for the continued viability of, the C-T-R policy.
