On Tue, Nov 3, 2009 at 4:03 PM, Eric Seidel <[email protected]> wrote:
> > Could we just automate rollouts and this "5-minute timer"? If we have > the tools to do automated rollouts, would it be reasonable to add them > as a phase in the buildbot? > I looked into this, and implemented a proof of concept, but ditched it because I don't think there was enough benefit. It is so easy to revert with drover than everyone can do it really fast, and if we automate it, we'll still need someone to sign off on it, because maybe the compile failure was a bot problem, or maybe it needed a clobber. We can't just blindly revert changes. Nicolas > > On Tue, Nov 3, 2009 at 2:52 PM, Nicolas Sylvain <[email protected]> > wrote: > > +1 > > > > On Tue, Nov 3, 2009 at 3:38 PM, Avi Drissman <[email protected]> wrote: > >> > >> I'm OK with that. > >> > >> Just make it clear that the sheriff does have authority. One time when I > >> was sheriff I wanted to revert a broken patch. The author insisted on > >> patching it over and over. He finally got it working about about seven > >> patches and nearly three hours or so, when I was insisting on backing it > out > >> after the first 30m. > > > > Yes, this is exactly what we want to avoid. > > The 2-minute rule usually includes: > > "Oops, I forgot to commit a file" > > "Let me disable the test I just added, it clearly does not work" > > "Oops, before committing I renamed a variable and forgot to change it at > one > > place" > > It also use to mean: > > "Oops, I forgot an include". But this one has been biting us to much in > the > > past, so I leave it at the discretion of the sheriff. > > I think people need to use their good judgement too. The length of a > minute > > should be inversely proportional to the number of people trying to commit > > during this time of the day. > > Nicolas > >> > >> Avi > >> > >> On Tue, Nov 3, 2009 at 5:34 PM, Peter Kasting <[email protected]> > wrote: > >>> > >>> On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai <[email protected]> wrote: > >>>> > >>>> To be clear, here's the proposed policy: Any change that would close > the > >>>> tree can be reverted if it can't be fixed in <2 minutes. > >>> > >>> How about: > >>> If a change closes the tree, the change author has 1 or 2 minutes to > >>> respond to a ping. The change should be reverted if the author doesn't > >>> respond, if he says to revert, or if he does not say he has a fix > within the > >>> next 5 minutes. > >>> I can't fix _any_ problem in 2 minutes. But I can fix most of them in > 5. > >>> The goal is to allow the author a reasonable chance to fix trivial > problems > >>> before we revert. And I think the tree should go ahead and close > during > >>> that interval. > >>> PK > >>> > >> > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
