HOWTO schedule an issue for backporting » History » Version 12
Loïc Dachary, 11/17/2015 07:43 PM
| 1 | 3 | Loïc Dachary | h3. First stage |
|---|---|---|---|
| 2 | |||
| 3 | 4 | Loïc Dachary | Although this can be done by the backporter when (s)he notices an issue should be backported, it is usually done by the original developer when (s)he realizes the fix must be backported. |
| 4 | 3 | Loïc Dachary | |
| 5 | 2 | Loïc Dachary | * Add the name of the release to the comma separated list of release in the **Backport** field of the issue (see "journal Unable to read past sequence 406":http://tracker.ceph.com/issues/6003 for instance). |
| 6 | 1 | Loïc Dachary | * Change the issue status to *Pending Backport* |
| 7 | |||
| 8 | 3 | Loïc Dachary | h3. Second stage |
| 9 | |||
| 10 | This is not expected from the developer, it is the responsibility of the backporter. |
||
| 11 | |||
| 12 | 12 | Loïc Dachary | "ceph-workbench":http://ceph-workbench.readthedocs.org/ <code>backport-create-issue --redmine-key $redmine_key --dry-run</code> |
| 13 | 6 | Loïc Dachary | |
| 14 | h3. Backport field in the commit messages |
||
| 15 | |||
| 16 | 7 | Nathan Cutler | Calling for backport by including a line like <code>Backport: firefly</code> in the commit message is discouraged because the commit message is immutable. An issue in the *Backport* tracker of the corresponding project at http://tracker.ceph.com/ should be created instead. Or, if the commit is associated with an existing issue, the *Backport* field should be updated with a comma-separated list of desired backports. Use release code names, not version numbers. |