Wes, Thanks for clarifying this. This will be very helpful for me while I work on the Rust DataFusion crate since we have a small number of committers today. I will still generally make PRs available for review (unless they are trivial changes) but being able to merge without review when the other committers are busy will be very helpful for momentum with some of the features that I would like to see in the 1.0.0 release.
Thanks, Andy. On Sat, Oct 12, 2019 at 2:51 PM Wes McKinney <wesmck...@gmail.com> wrote: > hi folks, > > We've added many new committers to Apache Arrow over the last 3+ > years, so I thought it would be worthwhile to review our commit and > code review policy for everyone's benefit. > > Since the beginning of the project, Arrow has been in "Commit Then > Review" mode (aka CTR). > > https://www.apache.org/foundation/glossary.html#CommitThenReview > > The idea of CTR is that committers can make changes at will with the > understanding that if there is some disagreement or if work is vetoed, > then changes may be reverted. > > In particular, in CTR if a committer submits a patch, they are able to > +1 and merge their own patch. Generally, though, as a matter of > courtesy to the community, for non-trivial patches it is a good idea > to allow time for code review. > > More mature projects, or ones with potentially contentious governance > / political issues, sometimes adopt "Review-Then-Commit" (RTC) which > requires a more structured sign-off process from other committers. > While Apache Arrow is more mature now, the diversity of the project > has resulted in a lot of spread-out code ownership. I think that RTC > at this stage would cause hardship for contributors on some components > where there are not a lot of active code reviewers. > > Personally, I am OK to stick with CTR until we start experiencing > problems. Overall I think we have a healthy dynamic amongst the > project's nearly 50 committers and we have had to revert patches > relatively rarely. > > Any thoughts from others? > > Thanks > Wes >
