Our recent status report raised a question from one of the reviewers about our commit policy, specifically about the following comment on it on our project page:
Except where noted, all stdcxx committers follow the Review Then Commit policy. From the stdcxx section of the Wiki page: http://wiki.apache.org/incubator/May2007 iPMC Comments: * jukka: I'm qurious about http://incubator.apache.org/stdcxx/#committers. Why some people are following CTR and others RTC? I thought it would be useful for us to discuss and clarify our policy with respect to commits. The policy we have in place ("Review-Then-Commit except as noted") is intended to prevent regressions on rare platforms that most committers don't have access to and are unable to test their changes on by giving those of us who do have access to and an extensive experience with such platforms the opportunity to review and give feedback on such changes. I think it still is a reasonable policy in general but I also think that, when applied rigidly, it could get in the way of productivity. Small changes, or changes that are obviously safe, can be committed immediately without requiring people to go through the review-then-commit process. At the same time, big changes should probably be reviewed before committed, regardless of who makes them and what platforms they have access to. So I would like to propose that we all follow a relaxed form of the Review-Then-Commit policy, where "simple" or "obviously safe" changes be allowed to go in under the Commit-Then-Review process. I don't think it's necessary to precisely define what "simple" or "obviously safe" means. It's a judgment call. Does this sound reasonable to everyone? Are we ready to have a vote on this proposal? Martin
