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.
Regards,
Graham
--
