lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: [Lucene.Net] Procedure for Commiting
Date Mon, 14 Mar 2011 15:40:31 GMT
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

Mime
View raw message