Project

General

Profile

HOWTO schedule an issue for backporting » History » Version 3

Loïc Dachary, 05/22/2015 09:14 AM

1 3 Loïc Dachary
h3. First stage
2
3
Although this can be done back 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
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
* visit the list of pending backports for the release (for instance "pending hammer backports":http://tracker.ceph.com/projects/ceph/issues?query_id=77)
13
* each issue should have a number of *Copied from* related issues that matches the number of releases in the *backports* field
14
* for each issue that misses at least a *Copied from*, visit the issue
15
* *copy* the issue (link on the top right of the issue)
16
** change the *Tracker* to *Backport*
17
** change the *Status* to *New*
18
** empty the *Description*
19
** keep the *Subject* as is
20
** set the *Release* to the target release
21
** unset the *Assigned* field or set it to the person who will work on the backport. It is usually wrong to set it to the developer who fixed the issue in master.
22
** unselect *copying attachement* if any (this only shows if the original issues had attachements)
23
** unselect *Include link to original story*