Re: Keep the world building - Best practices

[Xan Lopez <xan gnome org>]

Ok, so here's the WebKit side. I have tried to summarize the process,
leaving out (imho) useless details, since what I think in the end
matters is the flow and basic concepts.

- WebKit is supposed to work in a lot of different platforms and
environments, so the more complex a patch is the more likely it is
that it will fail to build in at least one of them. There's several
things done in order to try to prevent this from happening and, when
it happens, in order to fix it as soon as possible.

- All patches that go through bugzilla are built by the EWS (Early
Warning System)[1]. If they fail to build, you'll know already when
the patch is going through review, so you can iterate until things
work. This saves *a ton* of time for developers, but I guess it's not
practical for us to build all of GNOME for every patch submitted.
Maybe could be done per module, though.

- Once a patch has been accepted and has passed EWS, it's committed to
the mainline. There the buildbots[2] for each platform will again try
to build it (plus run all the tests, but since we are focusing on
building I'll ignore that for now). If the patch builds that's pretty
much it, otherwise they'll turn red and we go to the next step.

- People should pay attention to the buildbots after landing a patch,
but often they won't. A way in which WebKit tries to fix this is by
poking the patch authors through IRC and bugzilla (in the bug that
broke things) when their patch fails to build (or, again, fails some
tests), using a program called "Sheriff Bot"[3].

- If the problem is trivial people will often just fix things in
place, watching the bots as they go until they are green.

- If the problem is hard to solve, though, people will often tend to
just roll out the culprit patch. Sheriff Bot offers a really easy way
to create a reverse diff and commit it, just with one command
(sheriffbot: rollout <revision> <comment>).

**

What IMHO are the key features in here:

- WebKit gives you tools to test your patches ahead of time (EWS).
- There's buildbots and a web interface to see that everything goes OK
in live systems.
- When a patch breaks something, the system will notify the authors
(and everyone hanging out on IRC or following the original bug in case
they are not present).
- Tools are provided to easily roll out broken commits.

Xan

--

1: http://trac.webkit.org/wiki/EWS
2: http://build.webkit.org/
3: http://trac.webkit.org/wiki/Keeping%20the%20Tree%20Green