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


Ignore:
Timestamp:
Apr 9, 2013 9:39:55 AM (8 years ago)
Author:
thiago.santos@intel.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Keeping the Tree Green

    v9 v10  
    33In 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.
    44
    5 == Sheriffbot ==
     5== Webkitbot ==
    66
    7 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.
     7Webkitbot 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.
    88
    9 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).
     9Webkitbot 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).
    1010
    1111Q: Why wait for two failures in a row?
    12 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.
     12A: 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.
    1313
    14 Q: How does sheriffbot know my IRC nick?
     14Q: How does webkitbot know my IRC nick?
    1515A: 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.
    1616
     
    2121If 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.
    2222
    23 == Using sheriffbot to roll out a patch ==
     23== Using webkitbot to roll out a patch ==
    2424
    25 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:
     25Webkitbot 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:
    2626
    2727{{{
    28 sheriffbot: rollout 57047 This patch broke xyz test on Tiger
     28webkitbot: rollout 57047 This patch broke xyz test on Tiger
    2929}}}
    3030
    31 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.
     31Webkitbot 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.
    3232
    33 Q: Why do I have to mark the patch as commit-queue+, haven't I already told sheriffbot to roll out the patch?
     33Q: Why do I have to mark the patch as commit-queue+, haven't I already told webkitbot to roll out the patch?
    3434A: We don't trust commands received on IRC.  We need you to authorize the rollout using your bugs.webkit.org credentials.
    3535
    36 Q: Won't spammers create infinite bugs by poking the sheriffbot?
     36Q: Won't spammers create infinite bugs by poking the webkitbot?
    3737A: 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.
    3838