On 2011-03-14, Scott Lombard wrote: > I wanted to get a final agreement on how we want to handle commits to the > repository. There have been discussions in a couple of different threads > about this topic. I know patches, branches and just go for it has been > discussed and different people have different ideas. I just wanted to know > what the group thinks is the way to handle commits in our project.
Inside the ASF we have varying ideas about how to handle it. Many if not most projects use commit-then-review (CTR[1]) as their main model where you just commit and your peers review it later (that's why the commits mailing list exists). This is probably the quickest way to move forward but may lead to slipped-through problems. At the other extreme there are projects that require JIRA items for each and every commit with automated pre-build CI checks that reject patches attached to JIRA tickets if they break the build/tests/coding-standards/whatever[2]. This is probably the "safe" way but may keep people from contributing because the effort to get a patch in seems to big. Other projects live in some sort of middle ground where some branch is open for CTR and other branches (the "stable" branch) requires review-then-commit (RTC[3]). Many projects have written down policies like Hadoop which I've already cited or Solr[4]. I guess what I'm trying to say is there is no policy that would force you to do it one way or the other, it is your decision. Stefan [1] http://www.apache.org/foundation/glossary.html#CommitThenReview [2] http://wiki.apache.org/hadoop/HowToContribute [3] http://www.apache.org/foundation/glossary.html#ReviewThenCommit [4] http://wiki.apache.org/solr/CommitPolicy
