[webkit-dev] The tree is on fire: a tragedy of the commons
jorlow at chromium.org
Fri Feb 26 09:50:58 PST 2010
On Fri, Feb 26, 2010 at 6:47 PM, Dimitri Glazkov <dglazkov at chromium.org>wrote:
> 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?
Agree it sounds like a good plan.
Re the emails: who knows how to do that? Can someone own this process to
completion and do it as soon as possible? It'd be much appreciated!
> > -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
> >> 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
> >> patch, I have no problem with reverting. But if I can't immediately fix
> >> problem, because it's a platform specific issue, which can not be fixed
> >> 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
> >> 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
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev