Resubmitting a patch that was rolled out.

[johnj...@chromium.org]

I'm just asking about mechanics here: if a blink patch is rolled out due to a Chromium build failure, what should I do to try again?

1. Submit a completely new codereview.chromium.org issue with a modified patch using the same Chromium bug #?

2. git cl upload a modified patch on the previously closed codereview.chromium.org issue?

3. something else.

Thanks,

jjb 

[Dominic Mazzoni]

We had this discussion on chromium-dev not that long ago and no consensus was reached.

Some people use the same issue, others create a new issue. (Always use the same bug number.)

The main thing we can all agree on is, make sure it's easy for someone to figure out what happened from the commit log. If there's a BUG number associated with this issue, that may be sufficient - especially if it's a specific bug and this is the only patch needed to fix the bug. If not, the commit log should include the original commit revision, the revert, and the original code review issue, maybe even the reason for the revert & fix, etc.

- Dominic

[Dirk Pranke]

Dominic is correct that there isn't a consensus, nor are there any hard-and-fast rules we require.

I would reuse the same bug, create a new codereview issue, reference the original revision and codereview issue in the description, upload the original version of the patch (the one that was reverted), and then upload my revised patch. 

This has the advantages that we leave the original issue alone (one code revision == one issue) and then you get the full context of the diff in the new issue.

It has the disadvantages that there's a few more steps and any change-related discussions are split across the two changes. 

-- Dirk