Confirmed users
95
edits
TestEngineering/Performance/Talos/RegressionBugsHandling: Difference between revisions
TestEngineering/Performance/Talos/RegressionBugsHandling (view source)
Revision as of 18:09, 9 February 2015
, 9 February 2015minor edit
(new page: instructions on responsibility and handling of performance regression bugs) |
m (minor edit) |
||
| Line 22: | Line 22: | ||
** We're all responsible for the performance of the code we write, even if the regression is in an unrelated part of the codebase. | ** 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. | |||
** If the patch can't be backed out and you don't have time to work on it at the moment, make sure to file a follow-up bug to fix the regression, assign yourself and provide a timeline for the investigation & fixing. We should fix regressions before they reach Beta/Release users. | ** If the patch can't be backed out and you don't have time to work on it at the moment, make sure to file a follow-up bug to fix the regression, assign yourself and provide a timeline for the investigation & fixing. We should fix regressions before they reach Beta/Release users. | ||
The bottom line is that we want a visible decision on each case where the cause for the regression is known. | The bottom line is that we want a visible decision on each case where the cause for the regression is known. | ||