[webkit-dev] Landing your own patches

[Evan Martin]

On Wed, Oct 14, 2009 at 12:38 AM, Adam Barth <abarth at webkit.org> 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.