Project

Profile

Help

Task #90

Updated by bmbouter over 5 years ago

h3. Overview

Currently bugzilla.redhat.com has many feature requests in it. These feature requests (RFEs) need to be copied from Bugzilla and into Redmine.

This task involves migrating data between the systems using the Bugzilla and Redmine APIs in an automated way. Keep any code written in playpen of pulp/pulp so that it can be maintained over time. I recommend using one of the Redmine API bindings for Python that can be found on PyPI. Also looking for a bugzilla binding like bugzilla tools may be useful too. Finally, other projects do similar things with [0], so maybe borrow some from their code.

h3. When moving a RFE, you'll have to do the following

0) Ensure that all users from the cc list, the reporter, qe contact, and assignee all have redmine accounts so that we can associate the RFE correctly with the right accounts. Step 0 is about ensuring those accounts are there for each issue migrated to Redmine. You can create accounts for people in redmine here [1].

1) Create the Redmine redmine issue while porting over the following fields: description, priority, severity, status, reporter, assignee, QA-contact, version, and target release.

2) Port the keywords from Bugzilla. In Redmine these will be called tags. Populate the tags in Redmine as you find them, and specify the correct keywords on each Issue to match Bugzilla. There is 1 difference though. Do not port the 'FutureFeature' keyword. These keywords are no longer required in Redmine because using the Redmine Tracker type 'Story' will clearly indicate if it is a feature or not.

3) The entire history of the bug/RFE should be added into the notes or appended to the description in Redmine.

4) Put the new Redmine bug into the right Redmine "Project" [2]. What was a 'Component' in Bugzilla is equivalent to the different "projects" in Redmine.

5) Move any attachments also.

6) Add a link on the redmine issue that links back to the original Bugzilla location. Use the bugzilla field for this.

7) Mark the Redmine issue as a 'Story'. Redmine calls these things 'trackers'.

8) Ensure that the Redmine issue has the right 'watchers' watching it. 'Watch' in redmine means you'll receive an e-mail when an issue is updated. The set of watchers is like the 'cc list' in bugzilla. These can be set for a given issue through the RedMine API, see the watcher_user_ids field on Issues.

Note: you do NOT need to worry about 'blocks' field, those will be handled in a separate task #92.

h3. Here are the things you need to do to each Bugzilla that has been migrated

1. Once a RFE is copied into Redmine, the Bugzilla RFE should be CLOSED with the status UPSTREAM.


2. Add the keyword 'MoveUpstream' should be added to the Bugzilla RFE.


3. Also in Bugzilla there should be a 'External Tracker' called 'Pulp Redmine' which will accept an integer with the Redmine issue ID. This is how Bugzilla entries will refer to their Redmine counterparts.

4. Add a comment onto the Bugzilla that says 'Moved to XXXXX' where XXXXX is the fully qualified URL for the new Redmine issue. This is redundant with the info from step (3) but it will make it clear to those who don't look at the 'External Tracker' field.

h3. Which bugs are RFE's exactly?


Bugzilla RFEs contain the string 'rfe' in them or the keyword 'FutureFeature'. I have created a Bugzilla search[3] which should bugs which match either of these. There are ~125 bugs listed.

[0]: https://gitlab.sat.lab.tlv.redhat.com/satellite6/katello-team/blob/master/scripts/redmine_sync.py
[1]: https://pulp.plan.io/users
[2]: https://pulp.plan.io/projects
[3]: http://tinyurl.com/k2jfnwn

Back