Migrating your ASF project from Bugzilla to JIRA

(if you're looking for the JIRA FAQ, that page is JIRA.)

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

I've started collecting notes on how to do this in JIRABugzillaMigrationNotes.