Good point Sravya. I think adding criteria such as all changes > 100 lines
of code would overcomplicate things and be hard to follow. One of the goals
here is to be sure we have more than one set of eyes on a change before it
gets committed. Even though it adds a wait time for small patches, it could
help catch a problem where someone introduced an incompatibility in a
public interface with a tiny change. We could add an exception to
short-circuit the cool-off period if the change is to unblock the build - a
compile failure,  test failure, etc. That would ensure urgent patches can
still get committed quickly.

Thoughts?

Thanks,
Lenni



On Thu, Nov 12, 2015 at 6:49 AM, Sravya Tirukkovalur <[email protected]>
wrote:

> I think cool off makes sense in general, but i think it would be an
> unnecessary overhead for smallish patches, bug fixes, test fixes. Might
> create a dependency which can significantly delay development pace. But I
> do understand defining the criteria might be tricky, thoughts?
>
> Sravya
>
> > On Nov 10, 2015, at 6:26 PM, Sun, Dapeng <[email protected]> wrote:
> >
> > +1 for 24 hours.
> >
> > I usually waited for 24 hours and committed. I think people in community
> could join the jira discussion after jira created or patch available. 24
> hours is enough to give a buffer for people in different time zones.
> >
> > About the detail, how about "24 hours after first +1 if there's no
> objection"? We can also updated
> https://cwiki.apache.org/confluence/display/SENTRY/How+to+commit after
> discussion.
> >
> > Regards
> > Dapeng
> >
> > -----Original Message-----
> > From: Joe Brockmeier [mailto:[email protected]]
> > Sent: Wednesday, November 11, 2015 6:58 AM
> > To: [email protected]
> > Subject: Re: [DISCUSS] Cool off period for commits?
> >
> > Can you go into more detail how this would work?
> >
> >> 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/
>

Reply via email to