On Fri, Feb 26, 2010 at 6:47 PM, Dimitri Glazkov <dglaz...@chromium.org>wrote:
> 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? > 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! > > :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 >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev