Project

General

Profile

Actions

HOWTO schedule an issue for backporting » History » Revision 12

« Previous | Revision 12/14 (diff) | Next »
Loïc Dachary, 11/17/2015 07:43 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.

ceph-workbench backport-create-issue --redmine-key $redmine_key --dry-run

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.

Updated by Loïc Dachary over 8 years ago · 12 revisions