Project

General

Profile

HOWTO schedule an issue for backporting » History » Version 11

« Previous - Version 11/14 (diff) - Next » - Current version
Loïc Dachary, 11/04/2015 06:09 PM


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 for instance).
  • Change the issue status to Pending Backport

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)
  • each Pending backport issue should be copied to the appropriate backport tracker(s). That this has happened is indicated by the presence of lines like Copied to #11653 in the Related to column. There should be one such line for each target release
  • 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 Tracker to Backport
    • change Status to New
    • change Priority to Normal (if not already)
    • remove all text from the Description
    • keep Subject as is
    • set Target version to blank unless you know exactly which version it will go into
    • set Release to the target release
    • set Assignee to yourself if desired, otherwise to blank (do not leave the original value - Assignee should always be a member of the Stable releases and backports team)
    • 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

Backport field in the commit messages

Calling for backport by including a line like Backport: firefly 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.