HOWTO schedule an issue for backporting » History » Revision 8
Revision 7 (Nathan Cutler, 06/12/2015 08:40 AM) → Revision 8/14 (Loïc Dachary, 06/12/2015 09:24 AM)
h3. First stage 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. * 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). * Change the issue status to *Pending Backport* h3. Second stage This is not expected from the developer, it is the responsibility of the backporter. * visit the list of pending backports for the release (for instance "pending hammer backports":http://tracker.ceph.com/projects/ceph/issues?query_id=77) * each *Pending backport* issue should be copied to have a number of *Copied from* related issues that matches the appropriate backport tracker(s). That this has happened is indicated by the presence number of lines like <code>Copied to #11653</code> releases in the *Related to* column. There should be one such line for each target release *backports* field * for each issue that misses at least a *Copied from*, visit the issue * *copy* the issue (link on the top right of the issue) ** change the *Tracker* to *Backport* ** change the *Status* to *New* ** remove all text from empty the *Description* ** keep the *Subject* as is ** set *Target version* to blank unless you know exactly which version it will go into ** set the *Release* to the target release ** unset the *Assigned* field or set *Assignee* it to yourself if desired, otherwise the person who will work on the backport. It is usually wrong to blank (do not leave set it to the original value - Assignee should always be a member of developer who fixed the Stable releases and backports team) issue in master. ** unselect *copying attachement* if any (this only shows if the original issues had attachements) ** unselect *Include link to original story* * verify that the new issue shows as being *Copied from* in the list of related issues of the original issue h3. Backport field in the commit messages 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.