Confirmed users
356
edits
TestEngineering/Performance/Talos/RegressionBugsHandling: Difference between revisions
TestEngineering/Performance/Talos/RegressionBugsHandling (view source)
Revision as of 18:19, 9 February 2015
, 9 February 2015wording tweak
(added requirement for 3 days response and links to performance sheriffing) |
m (wording tweak) |
||
| Line 20: | Line 20: | ||
** If you think your patch is not to blame, we can re-trigger Talos test runs to confirm the before-and-after behavior. Talk to the person who filed the bug, they would be happy to help you figure out if the regression is real and if it is indeed your patch that is responsible. | ** If you think your patch is not to blame, we can re-trigger Talos test runs to confirm the before-and-after behavior. Talk to the person who filed the bug, they would be happy to help you figure out if the regression is real and if it is indeed your patch that is responsible. | ||
** It's up to the patch author to contact the right people (test authors, another team, etc) to figure out why the test regressed. | ** It's up to the patch author to contact the right people (test authors, another team, etc) to figure out why the test regressed. | ||
** | ** As a general rule, we're all responsible for the performance of the code we write, even if the regression is in an unrelated part of the codebase. | ||
* "I don't have time to deal with this right now" | * "I don't have time to deal with this right now" | ||
** This one can be valid (see "valid reasons" above). However, if the regression is quite large and you're pressed for time, consider backing the patch out and re-landing it when you have time to study its performance impact. | ** This one can be valid (see "valid reasons" above). However, if the regression is quite large and you're pressed for time, consider backing the patch out and re-landing it when you have time to study its performance impact. | ||