First, I want to clarify the current scenario for Curator, we are talking about a podling with pretty much ONE active committer.
Also, let me speak with my "Contributor" On Mon, Jun 3, 2013 at 4:14 PM, Josh Elser <[email protected]> wrote: > Speaking with my Apache Accumulo hat on: > > Contributors will typically attach the patch to the corresponding Jira > issue or use review board [1] > +1, non committers without a CLA is required to attach a patch to JIRA to properly give Apache the rights to use the contribution. Using review board might be a plu as it has a more user friendly UI for reviewing the code. > > The patch, ignoring very trivial changes, will typically hang around for a > while (probably due to the time until a committer has a moment to look at > it -- I like to think this gives everyone a chance to look at the changes > to give feedback despite us being a CTR [2] project). A committer who is > comfortable with the changes will typically be the "champion" behind it to > ensure it's up to snuff (matches code-style, no compiler warnings, works as > intended, has tests, etc), apply it, and merge it to any other branches as > necessary. > I think the "hang around for a while" is the biggest problem for a podling. If I'm a new guy trying the project, find some issues and provide a fix, and it hangs for awhile, I would either find another project that gives the same thing, or fork the project and most likely take it to the direction I want without caring about contributing the new changes Back. I also think that, because of this, a lot of corporations that don't have a lot of experience with OSS, might end up finding alternatives to handle the slow turnaround of patches that they provide. > > The only time a patch has come up for review/vote for us (as far as I > remember) is when the patch creates a controversial feature or there is > strong disagreement on the implementation of the changes. > Yes, vote usually don't happen often. But I think the question was more towards CTR versus RTC, and I'm definitely on the side of CTR. That's why we should learn how to properly evaluate new committers, and make sure we trust the new members of the project... once that relationship of trust is stablished, you can review the new commits (usually more thoroughly at the beginning) and discuss them in case of disagreement.... Establishing good design discussion best practices, where medium to small features should be discussed on the dev list first, having good test coverage, that can flag even style type of errors are also good, particularly when these are triggered before merge (e.g. in a gerrit x jenkins workflow) > > Hope that helps! > > [1] > https://reviews.apache.org/**dashboard/<https://reviews.apache.org/dashboard/> > [2] > http://www.apache.org/**foundation/glossary.html#**CommitThenReview<http://www.apache.org/foundation/glossary.html#CommitThenReview> > > > On 06/03/2013 05:08 PM, Jordan Zimmerman wrote: > >> ZooKeeper auto-applies patches. It's nice in that it does a first pass >> validation automatically. It's worthwhile, IMO. >> >> On this subject, what should our policy be on patches? Should we vote on >> every single one? How do other projects handle it? >> >> -JZ >> > > -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
