ApacheBugzillaToJiraMigration

Here are the steps for migrating your ASF project from Bugzilla to ApacheJira:

Step one: Agree to move

• Discuss it with your committers. If there is consensus, you can vote to migrate to JIRA.

Step two: Bugzilla data worth it?

• Determine whether you care what's in bugzilla now. JIRA has a project-import capability to get your existing issues in Bugzilla, but many projects are not actively using bugzilla or have almost no open issues and don't care about historical data.

Step three: Project structure

• You'll want to determine what projects you want setup in JIRA. You want to create one JIRA project for every versioned product you project you have. For some projects (like Maven and Avalon), this can mean 50-100 projects. To make this somewhat manageable, JIRA has project categories so users can more easily restrict to seeing their projects. As for components and versions in these projects, you can configure this yourself once your projects are setup.

Step four: Pick project key(s)

• The project key will be the prefix of every issue, for example, infrastructure's key is "INFRA" and issues are INFRA-1, INFRA-2, etc... This should be unique, but not too long. If you will have multiple projects, think about possible multiple keys.

Step five: List of developers

• Every visitor can create issues, make comments, and add attachments. Developers are able to assign issues, edit issues, close issues, move issues, manage releases, and other such stuff.

  Please ask every developer to create a JIRA account in advance. Then give us a list of usernames that we will associate with your permission scheme. If they have an existing bugzilla account, they must use the same e-mail address that they use with bugzilla.

  The way access control works in JIRA as of January 17, 2004, projects can use one permission scheme. We expect that for each ASF project, we will create exactly one permission scheme, and every developer will have full, useful rights in that permission scheme. If you really need more fine grained control, we can accomodate this, but would prefer you get comfortable with JIRA before making changes.

  Atlassian (makes of JIRA) say that in the 2.7 release (expected March/April 2004), there will be a greatly improved/overhauled permission system. We're looking forward to that.

Step six: Pick an administrator

• Right now JIRA cannot delegate the task of maintaining a Group (the list of users authorized to do something, such as work on your project in JIRA). As a result, we have asked each project to pick one person (typically a PMC member) who will be responsible for adding and deleting users from their group.

Step seven: Enter a Request in JIRA

• Create a Task in JIRA (project: Infrastructure, component: JIRA) with the following information you've collected above:

• vote results (nice to have link to mailing list thread)

• whether you want to import bugzilla data.

• list of projects (with keys... keys must alphanumeric, first 2 must be letters, will prefix all issue ids)

• if multiple projects, if there should be a shared developer group or each project gets its own group. The developer group will have rights to edit the issues.

• email address to send notifications (e.g., your developer email list). Make sure your mailing list is setup to accept emails from jira@apache.org or you will see no notifications.

• the email address of an administrator. this person will be granted JIRA admin access and is responsible for assigning developers to the project(s) group.

• send a message to your PMC and cc jira@apache.org of this request

Additional Notes for Migration

These notes were from a real-world migration of Avalon and XMLBeans.

• Official documentation on importing from Bugzilla

• administrator access is required

• mysql login info is required -- JIRA will ask for it in the "Import from Bugzilla" option.

• Project KEY : make sure you have one.

• Groups: migrating the project does not know who are the developers. You'll have to create a group for this project, and then start populating it with users (possible, see next).

• Have at least one person for the project that you can make a JIRA administrator and responsible for adding accounts.

• You need to know *email addresses* to map users to groups.

• Rumor has it that priority is not copied over on the bugs.

• Permission scheme, you'll need to create one. Do this after you've created the group. I recommend just creating a blank one than copying an existing. Basic scheme is:

  • jira-administrators can administer project, move issues, delete issues,

  • Anyone can browse project

  • jira-users can create issue, add comments, add attachments.

  • developers do everything except delete and set issue level security

• Notification scheme. I recommend copying an existing one for now so you get all the reporter/watcher notes right for now. This isn't as much of a pain as permission scheme is. Presently we are taking two approaches to notifications:

  • Have all notices go to the group. This means emails will be sent to individual email addresses and you rely on JIRA having all the appropriate accounts setup. I prefer this and have been setting up people this way.

  • Have all notices go to a single email address, namely the dev mailing list. Avalon had it setup this way, and I guess this allows a searchable, public record of this. I think this clutters the list and there's already a record of everything that happened in JIRA. This might be more in line with what people expect though, I'm not sure.

• When you first import a project, it will almost take more than 5 minutes to copy over, which means your browser will timeout. Once you start, go do something else for a while.

• Bugzilla changes

  • Mark the project as read-only so you can't create or edit issues.

  • Disable the email reports of open bugs