Changes between Version 9 and Version 10 of Keeping the Tree Green

Timestamp:

Apr 9, 2013 9:39:55 AM (11 years ago)

Author:

thiago.santos@intel.com

Comment:

--

Keeping the Tree Green

@@ -3 +3 @@
 In the past, red bots on http://build.webkit.org/waterfall went unnoticed and failures (including real regressions) accumulated in the tree.  The longer a failure persists in the tree, the harder it is to track down the source of the failure and the higher the chance that the failure is hiding another regression.  Keeping the tree green will requires effort on the part of every contributor but, in the end, makes the project more efficient.
 
-== Sheriffbot ==
+== Webkitbot ==
 
-Sheriffbot helps us keep the tree green.  If a core builder fails twice in a row, sheriffbot computes the blame list for the failure, notifies the responsible parties (committer, author, and reviewer) in IRC, and comments on the relevant bugs.
+Webkitbot helps us keep the tree green.  If a core builder fails twice in a row, webkitbot computes the blame list for the failure, notifies the responsible parties (committer, author, and reviewer) in IRC, and comments on the relevant bugs.
 
-Sheriffbot can't fix the tree himself: only you can prevent forest fires.  If sheriffbot complains about your patch, please take a moment to investigate whether your patch (or the patch you reviewed) actually caused a failure (ideally coordinating with other folks on IRC).  It's possible that your change broke the tree, but it's also possible that your change was blamed because it was caught in the same cycle as the change that really caused a failed (or it's possible sheriffbot was tricked by two flaky tests in a row).
+Webkitbot can't fix the tree himself: only you can prevent forest fires.  If webkitbot complains about your patch, please take a moment to investigate whether your patch (or the patch you reviewed) actually caused a failure (ideally coordinating with other folks on IRC).  It's possible that your change broke the tree, but it's also possible that your change was blamed because it was caught in the same cycle as the change that really caused a failed (or it's possible webkitbot was tricked by two flaky tests in a row).
 
 Q: Why wait for two failures in a row?
-A: We wait for two failures in a row to avoid spamming in the case of a flaky test.  That system isn't perfect, and we've seen cases where sheriffbot is fooled by flaky tests.  We're going to continue to iterate on the failure detection algorithm to reduce false alarms.
+A: We wait for two failures in a row to avoid spamming in the case of a flaky test.  That system isn't perfect, and we've seen cases where webkitbot is fooled by flaky tests.  We're going to continue to iterate on the failure detection algorithm to reduce false alarms.
 
-Q: How does sheriffbot know my IRC nick?
+Q: How does webkitbot know my IRC nick?
 A: We've add the IRC nicks for most members of the project to http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py.  Please take a minute to verify that your nick is correct or add your nick if it's missing.  Adding your nick to committers.py doesn't require review.
 
@@ -21 +21 @@
 If you cause a failure, please consider rolling out your patch instead of trying to fix the failure live.  There's no shame in rolling out your patch, and you can always land it again once you've tracked down the failure.  Often re-landing your change doesn't require an additional review.  Of course, rolling out a patch isn't appropriate for all situations.  The next time you find yourself trying to fix a failure live on the tree, ask yourself whether you're selfishly imposing costs on other members of the project.
 
-== Using sheriffbot to roll out a patch ==
+== Using webkitbot to roll out a patch ==
 
-Sheriffbot can help you roll out a patch.  Here's how it works.  Suppose revision 57047 broke Tiger.  You can send sheriffbot the following command in #webkit:
+Webkitbot can help you roll out a patch.  Here's how it works.  Suppose revision 57047 broke Tiger.  You can send webkitbot the following command in #webkit:
 
 {{{
-sheriffbot: rollout 57047 This patch broke xyz test on Tiger
+webkitbot: rollout 57047 This patch broke xyz test on Tiger
 }}}
 
-Sheriffbot will file a bug about the failure, cc the appropriate people, mark the bug as blocking the original bug, attach a rollout patch, and give you a link to the bug in IRC.  All you need to do is go to the bug and mark the rollout patch as commit-queue+.  The commit-queue will then land your rollout and reopen the origin bug.
+Webkitbot will file a bug about the failure, cc the appropriate people, mark the bug as blocking the original bug, attach a rollout patch, and give you a link to the bug in IRC.  All you need to do is go to the bug and mark the rollout patch as commit-queue+.  The commit-queue will then land your rollout and reopen the origin bug.
 
-Q: Why do I have to mark the patch as commit-queue+, haven't I already told sheriffbot to roll out the patch?
+Q: Why do I have to mark the patch as commit-queue+, haven't I already told webkitbot to roll out the patch?
 A: We don't trust commands received on IRC.  We need you to authorize the rollout using your bugs.webkit.org credentials.
 
-Q: Won't spammers create infinite bugs by poking the sheriffbot?
+Q: Won't spammers create infinite bugs by poking the webkitbot?
 A: We might need to restrict use of the rollout command to committers.  We'd still use bugs.webkit.org to authorize landing the rollout, but that should reduce the spam problem, if there is one.