[webkit-dev] The tree is on fire: a tragedy of the commons

Maciej Stachowiak mjs at apple.com
Fri Feb 26 11:53:46 PST 2010

On Feb 26, 2010, at 11:43 AM, Simon Fraser wrote:

> Mozilla has (or at least had when I worked there) two additional  
> "tree rules" that helped keep the tree green:
> 1. A sheriff was appointed at all times, and had the authority to  
> close the tree if there was significant build or test breakage.  
> Closing the tree meant that it was blocked to new commits other than  
> those intended to fix problems. Closing the tree also sends a strong  
> message that "something is broken, please pitch in and fix it if you  
> can".
> Sheriff duties were shared around between responsible committers, so  
> as not to overly burden one person.

I think the build sheriff idea is a good one. Maybe what we want is to  
have a sheriff responsible for each build train that has an active  
buildbot. (It could be the same person responsible for several build  
trains, the main qualification would be having reasonable familiarity  
with a port and access to its build environment.)

However, I am not so sure "close the tree" is necessarily the best  
focus for sheriff actions. What I'd prefer to see is that the sheriff  
the person primarily responsible for reverting broken patches if not  
fixed in a timely manner. Then we could have some human judgment in  
the process and specific people with clear responsibility.

> 2. The Mozilla tinderbox page (their buildbot waterfall) had a way  
> for people to leave comments, by adding a "star" to a particular  
> build with a comment. This is used as a way to communicate that  
> someone has noticed the breakage, and is working on it.

Sounds like a good idea. Wondering if that fits better in the console  
view or the extensions view.

> In general, I think the waterfall page could be improved in order to  
> make "breakage archeology" easier. Entries in the Changes column  
> should be direct links to trac changesets, for example.

That sounds good too. Another thing that would help is adding "next  
page" links to the console view, like we have on the waterfall. The  
console link often makes it easier to quickly identify the patch that  
went bad, but only if the badness is recent enough to show up.


More information about the webkit-dev mailing list