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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
