[webkit-dev] The tree is on fire: a tragedy of the commons

[Dimitri Glazkov]

On Fri, Feb 26, 2010 at 9:44 AM, Eric Seidel <eric at webkit.org> wrote:
> The bots take 15 minutes to cycle.  The moment the build is broken,
> thats FIX_TIME + BOT_CYCLE_TIME until their green again.
>
> I think we should cap the fix grace period at something like 15
> minutes, that means no more than 30 minutes of tree redness per break.
>  That might be too aggressive to start with for WebKit, but I think we
> should move towards that.
>
> I would re-write rule one as something like this:
> 1.  Comment in the bugzilla bug when the build breaks.  If there is no
> bugzilla bug, comment in #webkit.
> 2.  15 minutes after the break or 10 minutes after the comment, with
> no reply from the breaker, roll out the patch.

Sounds great. Is this going to be a new page on webkit.org?

:DG<

> -eric
>
> On Fri, Feb 26, 2010 at 9:32 AM, Nikolas Zimmermann
> <zimmermann at physik.rwth-aachen.de> wrote:
>>
>> Am 26.02.2010 um 18:17 schrieb Dimitri Glazkov:
>>
>>> To summarize the thread:
>>>
>>> 1) We're adopting "when in doubt, roll it out" approach to patches
>>> that turn tree red.
>>> 2) Need to find a way to run Mac-EWS for non-committers.
>>> 3) Enable "build-break" emails to webkit-dev or another opt-in mailing
>>> list
>>>
>>> What else?
>>
>> I'm a bit scared of rule 1. How about we define a minimum delay when to
>> roll-out patches, after they break something?
>> Let's say, if a commit breaks the tree, give the commiter a time frame of 30
>> minutes to fix it - otherwhise roll-out (we could even automate that.)
>>
>> Example: When landing a SVG patch, that worked fine on Leopard, but broke
>> Snow Leopard, I'd like to have some time to identify wheter it's the
>> fault of my patch, or a platform specific problem. If it's the fault of my
>> patch, I have no problem with reverting. But if I can't immediately fix the
>> problem, because it's a platform specific issue, which can not be fixed (in
>> terms of WebKit), then adding to the Skipped list, and filing a new bug
>> just takes 5 minutes. Reverting the whole patch, just to reland it with a
>> Skipped list addition is a bit too much work for me.
>>
>> What do others think?
>>
>> Cheers,
>> Niko
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>