+100.

This is very similar to getting paged about a production problem.
Sometimes you get sucked into wasting an hour on "easy" fixes which
don't fix anything.  That sets you up for stupid mistakes.

So, you broke the build.  Take it like a man/woman, revert your
change, and land it again when you've got it right.  It happens to
everyone.  The goal here isn't to save YOU ten minutes of time, the
goal is to save 5 minutes for each of the couple dozen co-workers
which will be impacted by the broken tree.  Only ask for grace to fix
the breakage if you're 100% certain you can fix it right the first
time.

-scott


On Tue, Nov 3, 2009 at 3:52 PM, Nicolas Sylvain <nsylv...@chromium.org> wrote:
> +1
>
> On Tue, Nov 3, 2009 at 3:38 PM, Avi Drissman <a...@chromium.org> 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 <pkast...@google.com> wrote:
>>>
>>> On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai <o...@chromium.org> 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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to