Hi devs,
Our Jira instance runs an unmaintained Jira Server version that can no longer be upgraded. Keeping it publicly reachable is a security risk, so we need to finish moving to OpenProject (see XWiki's next issue tracker (aka what's next after JIRA)) as soon as possible.
I’ve written a migration plan at https://design.xwiki.org/xwiki/bin/view/Proposal/JiraToOpenProjectMigration. Here’s a summary:
- All Jira projects move to op.xwiki.org, including contrib and retired projects. Contrib projects go first, then XCOMMONS, XRENDERING and XWIKI together on one weekend after a full dry run.
- Issue keys are kept (XWIKI-12345 stays XWIKI-12345) and new issues continue the numbering, so our commit conventions don’t change. All
jira.xwiki.org/browse/KEYlinks get permanent redirects. - Jira becomes read-only and non-public right after the last migration, then is switched off after a 3-month safety period. Note that this changes what I wrote last December (“keep Jira read-only”): given the security risk, we can’t keep it running.
- Data mapping:
- components become categories;
- XS versions are shared across XCOMMONS/XRENDERING/XWIKI (one version per release);
- resolutions become statuses (plus a new “Inactive” status for BFDs);
- Major priority becomes Normal, Minor and Trivial become Low.
- Commits are linked through GitHub autolinks plus a small bot, since OpenProject only links PRs.
- xwiki.org pages: about 23,200 Jira macro calls on about 3,800 pages. Every kind of usage (test reports, extension version notes, release notes, roadmaps, release plans) gets an OpenProject equivalent, and existing pages are converted by script.
- Tooling:
- The Jira version handling in our Maven release is replaced by an OpenProject equivalent.
- The CI flicker detection queries OpenProject.
- notifications@ keeps receiving issue changes.
- New contrib projects are created from an OpenProject template project.
- Security issues: the preferred option is to keep them in our tracker, using confidential work packages in OpenProject, and we’re asking the OpenProject team what the feature will cover and when. Plan B, if it doesn’t cover our needs or arrives too late for the XS migration, is GitHub Security Advisories (see Report security issues through GitHub Security Advisories instead of Jira). The choice gets its own proposal and vote once OpenProject has answered, and we won’t switch twice. Contrib projects that still have confidential issues in Jira move with the XS projects.
- Schedule: it depends on the OpenProject Jira migrator, with two milestones: T0, when it can import our contrib projects, and XS-ready, when it also handles what XCOMMONS, XRENDERING and XWIKI need (resolutions, issue links, labels, multiple categories, inline images, confidential work packages, reliable imports at the scale of XWIKI). Contrib projects move in the 4 weeks after T0, and the XS projects at the later of T0+6 weeks and XS-ready plus one dry run, followed by the 3-month safety period. We want to complete it ASAP.
- Also needed from OpenProject: a few features we can live without for a while thanks to temporary workarounds (e.g. linking pushed commits, OR filters, a Jira-compatible query layer). They’re listed on the design page.
Progress: once we agree on the plan, I’ll create a XINFRA parent issue with one sub-task per workstream, linked from the design page, and post a reply in this thread at each milestone (OpenProject’s answers, T0, each contrib batch, the XS migration, Jira read-only, Jira switched off).
How we use OpenProject will be documented on https://dev.xwiki.org/xwiki/bin/view/Community/IssueTracker/OpenProject/, which we’ll update as decisions are agreed.
Here’s my +1. Feedback is welcome, especially on anything missing or that you see as a blocker.
Thanks