Agavi! Blog Testing GitHub Tickets for the Migration

One thing we've always put a focus on is having tickets for every change we make, and using these tickets extensively in commit messages and from other tickets so a quick svn blame on a line not only shows a description of the change, but also gives a ticket number that can be looked up on Trac to follow a discussion of the change.On numerous occasions, I looked at a bit of code, found it to be incredibly stupid, but then did an svn blame anyway to figure out when the change was done. Looking up the ticket on Trac then usually gives a list of all the commits for that change, and maybe even related tickets and discussions. Often enough, that line of code then turned out to not be so stupid after all, and the day was saved.Good examples are tickets #502 or #1199, which link to related and duplicate tickets, have discussions in them and of course commits references.All these tickets contain valuable information, so it is vital to preserve all this history. However, the GitHub ticket API does not allow a timestamp in updates, which means that any ticket and any comment will have the date and time of import, and not the old date and time. Commits from the repository, however, will contain the correct timestamps as git2svn preserves that information.We tested how the GitHub issue tracker behaves with respect to timestamps, and found the following:For commits referencing a ticket (via "refs #123" or "closes #456") will use the timestamp of the commit for the reference, not the timestamp of the pushComments and commit references in tickets are in the order of their creation in the tracker, not in the order of their timestampsTickets that do not exist are not updated retroactively when referenced in a commit messageThe result is that we can now build a database of commits and ticket changes that are in the order of their timestamps, and replay them step by step, meaning that we will convert the repos, then push a commit, then replay a ticket update or creation, then push another commit and so forth. The result will be that a ticket might contain a comment (with a timestamp of, say, January 2 2012 13:04:12 because that's the time when our API client replayed that change) followed by a commit reference that closed the ticket (with a timestamp of, say, August 4 2007 08:09:12, because that's when that change was committed).Ultimately, this means that we will be able to use GitHub's native support for "refs #123" or "closes #456", which will look much nicer than manually having to construct comments through the API about commits referencing the issue.The remaining issue of course is that any comment and ticket will have the wrong date and time, so we'll have to include that in the next (along with a notice saying that the ticket/comment was migrated from the old Trac, just so people know), but it simply seems like there is no way around that with the GitHub API.Regarding severities and priorities, we might drop these altogether along with keywords; components can be done via labels, and so can ticket types (enhancement/task/defect) and versions. Milestones are supported natively by the GitHub issue tracker, so they won't be a problem.Certain changes in GitHub, such as changing milestones, labels or assignees, are not displayed in the web interface, even though the changes appear to be recorded internally and are available through the API, so the information itself is not lost.