When you check in something that breaks the build (compile failure, test failure), we should more proactively contact people who are on the hook for the bustage. This should include: * sheriffbot pinging them on IRC (this used to happen) * adding comments to bugs * sending email * sending text message to phone numbers
We have all the code to do this, but it's current disabled because it was too spammy. Maybe restricting it to compile failures would be a good way to make it non-spammy?
We have so much unnoticed build and test bustage that I'd rather it be too spammy. It should only spam those who've committed, which should make people more cautious before committing. That can only be a good thing.
The first step is (roughly) to revert http://trac.webkit.org/changeset/90636
I support this. Our last (long running) attempt at this seemed a failure. I think what you're seeking is cultural change more than technical change. Perhaps the technical can help the cultural with the right leadership.
Some ideas for reducing spam: 1) Instead of using Pass Fail Fail as the signal to bug people, we can use Pass Pass Fail Fail. That will filter out noise from tests that fail 90% of the time. 2) Rate limit messages from each test. If we've bugged someone about a given test already in the past 24 hours, don't bug anyone this time.
It's sad that the tree is more or less always half red / orange these days (and that's only the core builders). Currently if you want to make sure your patches don't break anything, you have first to get whoever broke the build to fix it first. Having sheriffbot yell at people had the upside of making it obvious that the person was contacted about it and when he/she heard about the breakage (in case a rollout needs to be done).
There are also too many builders in the core category. If a port hasn't even compiled in days, it should be removed.
We've also discussed making the sheriff-bot more agressive about contacting people who break the build in the past. See bug 36581.