Basic Preparations for GitHub Ticket Migration

Before modifying the ticket and comment contents themselves (to convert them from TracWiki syntax to Github Flavored Markdown), a few more fundamental changes are necessary:

1. Find missing ticket IDs (the Agavi Trac has 83 “gaps” in the ticket ID sequence; those were all spam tickets that got deleted, but not in time for a legit ticket showing up with a later ID in the database)
2. Compose a list of all ticket reporters, ticket change authors (e.g. people leaving a comment) and attachment authors and create a mapping to their GitHub user names or plain display names that will be used during import
3. Migrate all milestones to the GitHub issue tracker
4. Migrate all versions (as labels) to the GitHub issue tracker
5. Migrate all components (as labels) to the GitHub issue tracker
6. Migrate all ticket types (as labels) to the GitHub issue tracker
7. Do something about Priorities and Severities

1. Finding Missing Ticket IDs

That one is fairly easy:

$ sqlite3 trac.db 'SELECT id FROM ticket;' | php -r '
$ids = file("php://stdin", FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);
echo implode("\n", array_diff(range(1, max($ids)), $ids)) . "\n";
'

The resulting list needs to be stored somewhere for later, when we replay all ticket changes - that script will produce empty dummy tickets for the missing IDs to make sure all ticket IDs line up between Trac and GitHub.

2. List Ticket Reporters/Authors

We only need SQL for this:

sqlite3 trac.db '
SELECT DISTINCT (user || " = ") FROM (
    SELECT reporter AS user FROM ticket
    UNION ALL
    SELECT author AS user FROM ticket_change
    UNION ALL
    SELECT author AS user FROM attachment
) ORDER BY LOWER(user) ASC;
'

The result can be put into a file that is then filled by hand with references to people. In our case, we chose to use either a GitHub username (if known, requires some research in certain cases), half of the person’s e-mail address, or a nickname in quotes:

anonymous = "anonymous"
david = @dzuelke
steve@REDACTED.com = steve@…

“REDACTED.com” is obviously not what was really in there; the ellipsis (“…”) is correct however.

This map will be used by a script later when replaying ticket changes via the GitHub API in order to embed information about the original authors. By using GitHub usernames with the “@someone” notation, a link will be created; we just have to get things right on the first attempt or some people will complain about notification spam ;)

3. Migrate Milestones

Very straightforward as the GitHub issue tracker supports milestones. They existing milestones in the Trac database are simply ported over to GitHub; milestone “AgaviForge” will be dropped however (and the corresponding tickets later reassigned).

4. Migrate Versions (as Labels)

Versions as registered in Trac will simply be imported as labels like “0.10.2” or “1.0.8”. For now, we will import all versions except for “HEAD”, “HEAD-1.0” and “HEAD-0.11” since those only cause clutter and thus far have rarely been used.

This will create a considerable amount of labels just for the versions; we might eventually merge them all into series labels (like “1.0.x” or “1.1-latest”, similar to e.g. Ruby on Rails). When doing that, we might also drop old series labels that are not maintained anymore, simply to cut down on clutter.

One last thing to decide upon of course is the color codes for the versions. No great ideas yet, as the colors are shared with components and ticket types (see below).

5. Migrate Components (as Labels)

Components will be migrated to labels with identical names, with the exception of “documentation” (will be moved to a separate repository), “website” (never has been part of the SVN repos, but will be moved to its own GitHub repository eventually) and “OTHER” (no label will be assigned to such issues).

Again, color coding is something that’s left to be decided (suggestions welcome).

6. Migrate Types (as Labels)

There currently are just three issue types: “defect”, “enhancement” and “task”. Those will be migrated as-is, with defects getting a flashy red color, enhancements a nice green, and tasks… well… turquoise maybe?

7. Priorities and Severities

Priorities will simply be dropped, they have never proven to be useful. Same for severities, although we might have a dedicated label for blockers, indicating that resolving such an issue may not be postponed until a later release.