Swift moves its bug history into GitHub Issues

A bug tracker migration has to preserve more than the text of a report. The association between a report and its author is part of the data model, and the destination may not allow that association to be changed later. Swift's move from JIRA to GitHub Issues makes that constraint unusually visible. Contributors had to supply an account mapping before import if they wanted the resulting issue to identify them as its creator.

Mishal Shah's April 25 announcement confirms that the first phase has completed. The issues have been cloned into the apple/swift repository. Moving them into the GitHub repositories corresponding to their original components remains the next step. The announcement marks an important milestone, while leaving a distinction between imported history and its eventual placement.

I find Swift's design easier to appreciate when the reasoning behind a change is accessible. Compiler reports are part of that reasoning. Keeping reports near code review should make following a defect less dependent on knowing a separate tracking system and its conventions.

One tracker covered several repositories

The earlier migration plan explains why importing directly into a single permanent location would not reflect the project. JIRA contained issues for multiple Swift repositories. A component in that tracker represented information that GitHub's repository organization expresses differently.

The project therefore chose two phases. Each JIRA issue would first become a GitHub issue in apple/swift. After that, the new issues would transfer to the repositories that corresponded to their original components. Importing content and assigning its final repository were separate operations in the announced procedure.

That separation is useful when interpreting today's status. A Foundation issue appearing in the compiler repository during the migration does not imply that Foundation's ownership has moved there. The repository is also the initial destination for imported reports. Treating every issue's temporary location as a permanent ownership decision would misread the process.

The migration plan identifies integration with GitHub workflows, including pull requests, as the reason for leaving JIRA. A report and the change intended to resolve it can then live in the same hosting system. The expected benefit concerns how contributors discover and connect work. It does not establish that the technical substance of a report changes when its hosting location changes.

Authorship needs an explicit translation

JIRA usernames and GitHub usernames are separate identities. The migration could not assume that a matching name referred to the same person, or that every reporter already had a usable destination account. The plan asked contributors to enter both usernames in their Swift Forums profile so that the import could associate the accounts.

Unmapped reports would still migrate. Their creator in GitHub would be a bot account. The announcement states that the creator of a GitHub issue cannot be changed after creation, which made collecting the mapping before import a substantive requirement. A later comment explaining the original authorship would not be the same operation as changing the creator field.

This distinction is easy to miss when evaluating a migration by counting reports. An import can preserve the existence and contents of every issue while changing the account that the destination recognizes as its creator. The project explicitly called out that consequence, giving contributors an opportunity to affect it before the destination records were created.

The plan also required contributors to accept an invitation to the temporary migration organization. That requirement and the profile mapping formed part of the migration workflow. Moving public issue text alone was insufficient to reproduce the intended account associations.

I regard that warning as one of the most valuable details in the plan. A destination's immutable fields deserve attention before data transfer begins. They determine which mistakes can be repaired by editing an imported record and which require a different remedy.

The transition has several dates

The published schedule asked for username mappings by April 7 and invitation acceptance by April 18. It planned to make JIRA read-only on April 18, expose imported issues for read-only review on April 19, and transfer the imported set into apple/swift by April 25. GitHub Issues was scheduled to be available for use starting April 28.

Those are stages of the announced plan, not interchangeable descriptions of a single cutover. Today's confirmation establishes that the initial cloning phase has occurred. It does not establish that every later stage in the schedule has completed early. Separating planned availability from confirmed import keeps a progress report accurate for contributors trying to decide where to look.

Read-only review also has a different purpose from ordinary issue use. It gives the community a chance to inspect the imported representation before treating it as the normal working tracker. The published sequence puts that inspection between the old tracker's read-only transition and the scheduled availability of the new one.

The plan says that JIRA will stop accepting new reports after the migration. It also describes redirects from old bugs.swift.org URLs as future work. A preserved report and a preserved external link are therefore distinct deliverables. The April 25 announcement does not claim that the redirect work has already finished.

Report location is part of the contribution workflow

For a contributor reading today's announcement, the initial destination supplies a place to find the migrated history. The original component still matters because it determines where an issue is meant to go next. Information copied from JIRA should be interpreted alongside that announced mapping, especially while all imported reports share one repository.

The migration also changes what the project can connect within its normal development workflow. The earlier plan explicitly names pull requests as an integration problem with JIRA. Hosting reports and proposed fixes together reduces the need to cross between independent systems to follow the same piece of work. That is an organizational improvement even for defects whose reproduction and diagnosis remain difficult.

Swift's April milestone is therefore specific. The historical reports have entered GitHub, and the project has an announced process for transferring them to component repositories. Authorship mapping explains why some import decisions had to precede that milestone. The remaining repository transfers and planned URL redirects address different parts of preserving the reports' usefulness to contributors.