Task #90
Updated by bmbouter over 9 years ago
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]. following: 1) Create Move the 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 It would be called tags. Populate good if 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 were added into the notes or appended to the description in Redmine. 4) 3) Put the new Redmine bug into the right Redmine "Project" [2]. [1]. What was a 'Component' in Bugzilla is equivalent to the different "projects" in Redmine. 5) 4) Move any attachments also. 6) also 5) Add a link on the redmine issue that links back to the original Bugzilla location. Use the bugzilla field for this. 7) location 6) Mark the Redmine issue as a 'Story'. Redmine calls these things 'trackers'. 'Story' 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 a yet-to-be-created-in-bugzilla status UPSTREAM. 2. Add the keyword 'MoveUpstream' should of 'MOVED_TO_REDMINE'. Ideally, a custom field would be added to the Pulp Bugzilla RFE. 3. Also in that would allow the Redmine issue to be tracked when the Bugzilla there should RFE is closed. If that is not possible, then a comment can be a 'External Tracker' called 'Pulp Redmine' which will accept an integer added with the Redmine issue ID. This is how Bugzilla entries will refer URL to their Redmine counterparts. the new location in Redmine. Bugzilla RFEs contain the string 'rfe' in them or the keyword 'FutureFeature'. I have created a Bugzilla search[3] search[2] 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 https://pulp.plan.io/projects [2]: https://pulp.plan.io/projects [3]: http://tinyurl.com/k2jfnwn
.