Re: [DISCUSS] Review-then-commit (RTC) vs Commit-then-review (CTR)

2016-05-20 Thread Jakob Homan
It's up to each community to decide what it's comfortable with, and then make sure the process is applied equally to everyone. In my experience, 'non-minor, trivial' is pretty nebulous. Does a 3,000-line IDE-driven refactor count as non-minor? What about a one line change in the heart of the

Re: [DISCUSS] Review-then-commit (RTC) vs Commit-then-review (CTR)

2016-05-20 Thread siddharth anand
Can we suggest a +1 vote for non-minor/non-trivial commits, or do all commits require a +1? Or is the "non-minor, non-trivial" wording too nebulous. t feels like this would work better the more committers we have given our different daily work schedules. -s On Thu, May 19, 2016 at 5:56 PM, Jakob

Re: [DISCUSS] Review-then-commit (RTC) vs Commit-then-review (CTR)

2016-05-18 Thread siddharth anand
Thanks for sharing this information. All, Please share any additional thoughts. In a few days, I will kick off a VOTE thread to decide our process. Mentors, Just curious! Is there an automation we can use to ensure/enforce that PRs and JIRAs receive the +1 binding (from committers) votes needed

Re: [DISCUSS] Review-then-commit (RTC) vs Commit-then-review (CTR)

2016-05-18 Thread Jakob Homan
Hey- The consensus approval link is referring to votes (e.g. releases, new committers, new PMCers, etc) rather than code changes. A single +1 is standard for code changes, as Chris describes. However, projects are welcome to provide more fine-grained requirements as well. For example, Hadoop

Re: [DISCUSS] Review-then-commit (RTC) vs Commit-then-review (CTR)

2016-05-18 Thread Chris Riccomini
Hey Sid, > In the RTC case, we need 3 +1 binding (a.k.a. committer) votes This sounds very high. Usually one +1 (other than the person sending the) is normal in an RTC scenario. > In the CTR case, we may want a separate develop branch against which to run integration tests and merge to master