On Wed, Oct 14, 2009 at 12:38 AM, Adam Barth <[email protected]> wrote: > Has this actually been a problem? I know the commit-queue broke > something today when landing a patch for Evan Martin, but he was on > IRC and I made sure he was on the hook to watch the bots before I had > to leave. If I've landed things via commit-queue and not cleaned up > after them, I certainly apologize. Eric has talked about having the > commit-queue watch the bots and send out email to the appropriate > people when the commit-queue breaks something.
This is kinda derailing the thread, since Sam was just asking committers to not use the c-q bot, but since you brought it up... I think the lesson I've learned with this change is that I shouldn't tackle "hard" bugs to get started in WebKit. The patch that broke affected all platforms and touched how CSS values are presented to JS, so it was no surprise to me that it broke something. If I'd had commit access I would've been able to check in/out my patch immediately when I saw I broke the non-Mac platforms; as it was I begged someone to cq+ my r+'d patch, came back 20 minutes later to see that the commit bot flaked, begged someone to set it again, came back 30 minutes later to learn I'd broken the build, and then had to pawn off cleaning up the breakage on dglazkov since I couldn't revert it. :( It seems reasonable enough to me to require me and others start small. There are plenty of bugs I'd like to convert into tests. Yesterday I landed two cosmetic (widget rendering) changes that only affect Chrome and aren't even covered by any webkit.org builders. Though I worry that means that only people who have taken the time to become committers will ever be able to make large changes. (The alternative technical solution is to improve the c-q bot to test on all platforms, but that still leaves the revert problem.) > What I see as more of a problem is the failing tests on Tiger and > SnowLeopard the past few days. Having red columns on the tree makes > it harder to see when a new regression is introduced. I apologize for my noobness, but I've never been able to understand the webkit buildbots since a lot of them are red all the time. Is this documented anywhere? If not, I volunteer to make the website mods to document this if anyone is willing to explain it to me on a casual level. From a glance at build.webkit.org it seems the leaks bot and the GTK bots will always be red (and the Qt one is borderline). One thing that's helped a lot on Chrome is to split the bots into "if these break, revert your patch" (the builders seen on http://build.chromium.org/ -- in theory the big box at the top should be all green), and then "these bots are tracking stuff that we'd like to keep working" (the builders seen on http://build.chromium.org/buildbot/waterfall.fyi/console). Or to use different colors (red = something has gone horribly wrong, orange = this is broken but maybe ok), for example tracking compile failure vs layout test fails. _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
