[webkit-dev] Landing your own patches

[Adam Barth]

On Wed, Oct 14, 2009 at 9:21 AM, Evan Martin <evan at chromium.org> wrote:
> I think the lesson I've learned with this change is that I shouldn't
> tackle "hard" bugs to get started in WebKit.

I agree that it's a good idea to start small, the same way the
Chromium project asks new contributors to start small.

> 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.
> :(

Normally I would not have cq+'ed your patch and then disappeared.  I
did that because you seemed enthusiastic about getting your patch
landed and, in the worse case, I figured Tony could help dig you out
of whatever hole I put you in because his desk is right next to yours.

> It seems reasonable enough to me to require me and others start small.

There's certainly no requirement to start small.  It's more work to
interact with the project without the commit bit, but it's certainly
possible.

> 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?

WebKit doesn't have the same "green tree" aesthetic as Chromium does.
I think the main reason is because WebKit gets about half as many
commits per hour as the main Chromium tree and the commits are more
spread out over a 24hr period.  Another reason is that the GTK and Qt
ports have fewer maintainers than the Mac and Windows ports.  If we
were to close to tree whenever a bot went red (including the GTK and
Qt ports), folks who were less interested in maintaining those ports
would end up devoting more time to those ports.  However, the project
itself doesn't want to play favorites, so we don't want to have an
official policy of "close the tree for Mac and Windows redness."

Over time, the WebKit tree has been getting greener.  When I started
working on the project, all the bots were red all the time.  The
current unofficial culture seems to be as follows:

1) Ensure your change does not introduce new test failures on Mac or
Windows by comparing the list of failing tests before and after your
change (mentally filtering out the flaky tests).

2) If GTK or QT is compiling before your change, make sure GTK and QT
are compiling after your change.

3) If you notice someone disobeying rules (1) or (2), either ping them
on IRC or send them email.

> 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.

The problem with this approach here is that it is counter to the
cultural norm of not playing favorites with the ports.

Adam