On Tue, Nov 10, 2015 at 2:57 PM, Joe Brockmeier <[email protected]> wrote:
> Can you go into more detail how this would work? > Currently, the requirements for a patch to be committed are: 1) Patch posted to JIRA 2) Patch reviewed, gets +1 from a committer 3) All tests pass (automated by our pre-commit checks) Under the new proposal, an additional requirement would be added (the "cool-off period"): 1) Patch posted to JIRA 2) Patch reviewed, gets +1 from a committer 3) All tests pass (automated by our pre-commit checks) 4) Wait 24? hours from step 1). The goal of this are to allow more time for others in the community (who are potentially in different timezones) to provide feedback on the change before it gets merged. We could have an exception for the cool-off period if the change is to fix a broken build. The downside is that we are not able to execute as quickly since we must wait for the cool-off period before committing and must remember to go back to commit patches once the cool-off period has completed. > > On Tue, Nov 10, 2015, at 02:25 PM, Lenni Kuff wrote: > > Currently Sentry has not policy in place for a cool off period for > > commits > > (time after patch has gotten +1'ed that the change can be committed). > > This > > limits the opportunity other people in the community can review a change > > prior to it going in. This is particularly important since we have > > committers across many different time zones > > > > What do you all think about adding a cool-off period for all commits > > after > > a patch has gotten a +1? The Hive project uses 24 hours, so we could go > > with that. Could also use something longer like 48 or 72 hours. Thoughts? > > > > Thanks, > > Lenni > > > Best, > > jzb > -- > Joe Brockmeier > [email protected] > Twitter: @jzb > http://www.dissociatedpress.net/ >
