On Fri, Feb 26, 2010 at 9:44 AM, Eric Seidel <e...@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 > <zimmerm...@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@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev