When a change is identified that causes a regression and the best way to handle it is to back out the change, anyone can do so. It will still go through the standard code review process, but is considered a trivial change and thus it requires only one Reviewer and will avoid the 24h code review window. The idea here is to save time by not having a broken change hindering others. There is also the rationale that the change itself is automatically created by hg, and reviewed by the person who is performing the backout, so only one additional reviewer is required. There are two parts to this task, how to do the bookkeeping in JBS, and how to do the actual backout in mercurial. How to work with JBS when a change is backed out- Close the original JBS issue and mark it with "Fix Failed", which is an alternative on the "Verify" action.
- If the intention is to fix the change and submit it again, create a redo-issue to track that the work still needs to be done. Clone the original JBS issue and use prefix [REDO] on the summary.
- Make sure relevant information is brought to the clone.
- Create a backout-issue:
- Alternative 1 - a regression is identified directly. Create a Sub-Task to the redo-issue with the same summary, but prefix with [BACKOUT].
- Alternative 2 - an investigation issue is created, and during the investigation backing out the change is identified as the best solution.
- Use the investigation issue for the backout.
- Change summary to the same as the issue to back out and prefix with [BACKOUT].
- Link the redo-issue and the backout-issue.
- Alternative 3 - no redo issue was created. Create a backout-issue with the same summary, but prefix with [BACKOUT].
- Link the backout-issue and the original issue.
| Note |
|---|
- Remember that comments are not brought over.
- Quarantine and exclude labels will continue to point to the original bug (unless updated at back out). This is accepted since there is a clone link to follow.
|
How to work with mercurial when a change is backed outIn order to backout a change, the hg backout command is recommended, which essentially applies the anti delta of the change. Make sure you perform the backout in the most upstream repostiory the change has escaped to. | No Format |
|---|
hg backout [OPTION]... [-r] REV
reverse effect of earlier changeset
Prepare a new changeset with the effect of REV undone in the current
working directory.
If REV is the parent of the working directory, then this new changeset is
committed automatically. Otherwise, hg needs to merge the changes and the
merged result is left uncommitted. |
|