[webkit-dev] Frustrated at inconsiderate behavior

[David Levin]

What I noticed wrt the commit queue is that when a "core" build is broken
continuously for days (like what happened with the Chromium Linux bot
earlier this week for example), it causes big problems for the commit queue.

Perhaps a 12 hour rule would be sufficient -- the cq doesn't submit if a
builder is red unless if the builder been red for >= 12 hours. (Of course,
someone would have to code and I'm not sure if this could be easily this
could be determined). Also, we'd have to be aggressive about what btos would
be included in this list.

dave


On Thu, Jul 8, 2010 at 3:49 PM, Daniel Cheng <dcheng at chromium.org> wrote:

> On Thu, Jul 8, 2010 at 15:38, Xan Lopez <xan at gnome.org> wrote:
>
>> Aren't you essentially saying that you like the change because it
>> allows you to join the fun of adding code to already broken trees?
>> Again, I don't see how this helps us to move towards
>> as-greener-as-possible trees.
>>
>> If core-builders are repeatedly red for days on end this is something
>> we should address instead of adding workarounds so that people can
>> keep working without paying attention to it. It has been noted that
>> this is an often visited topic and off-topic to the thread, though.
>>
>> Xan
>>
>
> What I'm saying is that if the commit queue behavior is reverted, there
> ought to be some sort of policy (strong suggestion? rule?) in place for
> committers to discourage committing on top of a red tree as well. Maybe
> there's already one, but it's not strongly enforced and it's very easy to
> ignore if you just want to land your patch and start working on something
> else. For what it's worth, it was especially frustrating for me since I was
> only updating an interface in the Chromium platform layer and the 3 day
> delay blocked me from landing any of the associated patches on the Chromium
> side.
>
> Daniel
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100708/b3fa0bca/attachment.html>