JIRA Migration

MPDL =JIRA 3.X to JIRA 4.0 Migration=
 * this page will try to gather all necessary information for the JIRA 3.x to JIRA 4.0 Migration

Pre-requisites

 * check if current JIRA 4.0 installation is stable

General proposal

 * use JIRA default workflow wherever possible (to simplify)
 * use JIRA default issue types wherever possible (to simplify)
 * usernames: at the moment in JIRA old installation the user-names are defined based on the email address.
 * We need to set-up new usernames (as aliases) to deal with evtl. future public JIRA projects
 * Note: testing shows that public can browse projects, but can not see the user-profile in details (login for this is required)

PubMan Projects

 * Before migrating to JIRA 4.0 it would be good to merge the projects in the following manner:

Merging of projects

 * PubMan project (JIRA 4.0) to be merged from
 * Application Services (only opened issues)
 * PubMan Bug Tracking
 * PubMan Bug Tracking Admin (only opened issues)


 * check what to do with the PubMan Testing Scenarios project as this is indeed separate one
 * check if should be merged together with PubMan, or should undergo indeed separate workflow - thus separate project
 * --Ulla 17:36, 11 February 2010 (UTC) Feedback SvM Meeting: For all solutions, the project on testing scenarios should be maintained as separate projects, but much more simplified. The current set up of http://zim01.gwdg.de:8080/browse/FACTS is an example of already simpliefied testing project.

Workflows

 * Each of projects defined for merging do have different workflow.
 * Proposal: The workflow should be simplified to the JIRA4 default workflow (see http://confluence.atlassian.com/pages/viewpage.action?pageId=185729618 for more information)


 * Fine with me. --Ulla 10:05, 24 November 2009 (UTC)

Issue Types

 * Application services project has following issue types:
 * Specification Task
 * GUI Design Task
 * GUI Implementation Task
 * Design task
 * Implementation Task
 * Maintenance Task
 * Improvement
 * New Feature
 * CoreServiceTest - to be removed
 * Task
 * Sub-task (sub-task)
 * Scope Agreement - to be removed


 * PubMan Bug-Tracking, and PubMan Bug-Tracking Admin project have the following issue types (all can be mapped to the default issue type schema):
 * Task
 * Bug
 * New Feature
 * Improvement
 * Sub-task (sub-task)


 * Proposal (use the following issue types, default scheme):
 * Bug (mapped from Bug above)
 * New Feature (mapped from New Feature above)
 * Task (all Tasks from above i.e. GUI Design Task, GUI Implementation Task, Design Task, Implementation Task, Maintenance Task, Task, Specification Task)
 * Improvement (mapped from Improvement above)
 * Add subtasks as regular issue types(?, to be checked how it works with GreenHopper)
 * fine with me. Not sure on the need for issue type "Sub-Task": If we can still link issues (and therefore define semantics of linking), I do not think "subtasks" are needed.--Ulla 10:04, 24 November 2009 (UTC)


 * --Ulla 16:50, 10 February 2010 (UTC)What about the components for each project? Would they be same for all projects or can we still define different components per project?
 * for each project components can be defined separately as before. But when we move these issues together components need to be merged first.

Merging of projects

 * FACES project (JIRA 4.0) to be merged from
 * FACES (only opened issues)
 * FACES Bug Tracking

Workflows

 * analogue as for PubMan

Issue Types

 * analogue as for PubMan

Merging of projects

 * VIRR project (JIRA 4.0) to be merged from
 * VIRR (only opened issues)
 * VIRR Bug Tracking

Workflows

 * analogue as for PubMan

Issue Types

 * analogue as for PubMan

Support projects
I would keep them, even if it's only for having some kind of statistics which question has arisen most frequently it's useful, at least the handling in Jira is more comfortable than in the mailing-list-archive. Bartosch 15:58, 24 November 2009 (UTC)
 * At present there are three support projects:
 * Faces Support
 * PubMan Support
 * VIRR Support
 * ToDecide: keep them or discard them?
 * These projects are automatically populated in JIRA from the mailing list and are not further modified
 * --Ulla 17:38, 11 February 2010 (UTC) Feedback SvM Meeting: For Faces and Virr, the support projects can be ignored, i.e. do not have to be migrated at all as not used. For PubMan, we would like to propose the same, but still need to check with Malte.


 * JIRA migration requires all projects to be migrated. If not needed in future these can be deleted or archived. --Natasa 14:08, 4 March 2010 (UTC)

Note on closed/deleted projects
Closed projects are still present in JIRA can be browsed only by JIRA administrator user. For clarity they are not browsable and viewable by anyone else.

These are all assigned with "Closed project permission scheme".


 * Closed projects
 * FACES
 * VIRR
 * Application services
 * Infrastructure


 * Deleted projects
 * MPDL Berlin - no issues existed