Proposal for a Backport tracker

[Loic Dachary <loic@dachary.org>]

[-- Attachment #1: Type: text/plain, Size: 4440 bytes --]

Hi,

When an issue such as http://tracker.ceph.com/issues/9806 needs backporting, 

 * its status is changed to Pending Backport
 * the backport field is modified to contain the target stable releases
 * the severity field is modified to reflect the urgency of the backport

(see also http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO_schedule_an_issue_for_backporting). When a backport is ready for a given stable release, a comment is added with something like:

  * firefly backport https://github.com/ceph/ceph/pull/XXX is added to the issue

(either manually or in a semi automated way, see http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO_backport_commits). 

From time to time the Pending Backport issues are scrubbed to resolve those that have been successfully backported to all the desired stable releases (see http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO_resolve_issues_that_are_Pending_Backport for details).

This is not too complicated to explain and not too tedious to maintain. The only pain point is that we use the original bug report to track backports. It would probably be easier to have a separate issue, in a separate tracker to followup on the backports. It could go like this:

When an issue such as http://tracker.ceph.com/issues/9806 needs backporting, 

  * its status is changed to Pending Backport
  * the backport field is modified to contain the target stable releases
  * a backport issue is created in the "Backport" tracker and is "Related" to the original issue (probably using a script parsing the content of the backport field and not manually)
    * the issue is assigned to the backporter who will work on it
    * the release field of the backport issue is set to the target stable release (hammer, firefly, ...)
    * the Priority field is modified to reflect the urgency of the backport (it may be urgent for hammer and not for firefly, a distinction that is currently lost and using the severity field is kind of confusing because most if not all developers and predefined queries are looking at the value of the Priority field, not the severity field)
 
When a backport is ready for a given stable release:

  * the "Backport URL" field of the backport issue is set to the corresponding pull request or commit (sometime backports are not via a pull request, but all backports do have at least one URL)
  * when the backport is merged the issue is closed

From time to time, the "Pending Backport" issues for which all related issues from the Backport tracker have been closed are also closed. This step could even be entirely automated.

An additional benefit of having this separate tracker is that issues that require a non trivial backport could be assigned to a developer instead of a backporter and be discussed during bug scrub when reviewing http://tracker.ceph.com/projects/rbd/issues?query_id=27. There only are a handfull of them: for instance http://tracker.ceph.com/issues/9806 could be assigned to Josh and during bug scrub it would show to be from the Backport tracker.

The developer would not have to create issues to schedule a backport: (s)he would just update the backport field as (s)he currently does. The backporter will then be in charge of creating the issues. Most likely with a script creating the issues based on the content of the backport field instead of doing it manually. Having the developer create one issue per backport would not be good for two reasons : it would require explaining and it would be more work.

The justification for having a different tracker instead of using an existing one for the backport issues is primarily because the tracker shows in a number of pre-existing custom queries such as http://tracker.ceph.com/projects/rbd/issues?query_id=27. It's a easy way to convey the information: this issue is about backporting. A secondary benefit is that it's possible to define a workflow specific to a tracker, which could be interesting in the future because the backport workflow is not the same as the bug fixing workflow.

This is just an idea and I did not think this through. I like it right now but it just occurred to me this morning, after reading a mail from Josh who suggested we need a way for issues such as #9806 to be visible during bug scrub. Feel free to criticize bluntly, I won't be offended ;-)

Cheers

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]