[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.
Regards,
Maciej
More information about the webkit-dev
mailing list