[devel at bb.net] [users at bb.net] Weekly Meeting Notes

[Ryan Schmidt]

> On Sep 27, 2016, at 12:14 PM, Dustin J. Mitchell <dustin at buildbot.net> wrote:
> 
> NOTE: discussion of moving off of Trac below -- we would love to hear more opinions!

> 	• move tickets/wiki to github (djmitche, 16:46:44)
> 		• pro: github PRs and trac tickets do not interlink well; using github only would take advantage of github's integration (djmitche, 17:01:08)
> 		• pro: github takes care of fighting spam so we don't have to (djmitche, 17:01:35)
> 		• pro: everyone has a github account, whereas many do not want to sign up for Trac for a small issue (djmitche, 17:02:21)
> 		• (regarding spam, this also prevents people from creating accounts quite frequently) (djmitche, 17:02:57)
> 		• pro: less infra requirements if we're not running our own Trac (djmitche, 17:03:08)
> 		• con: different wiki markup language, so porting wiki pages would be tricky (djmitche, 17:04:11)
> 		• (although pandoc would help there) (djmitche, 17:05:48)
> 		• https://github.com/mavam/trac-hub (bdbaddog1, 17:07:23)
> 		• http://stackoverflow.com/questions/6671584/how-to-export-trac-to-github-issues (bdbaddog1, 17:07:56)
> 		• AGREED: interested parties will draft a plan, circulate on mailing list, and discuss in next week's meeting (djmitche, 17:12:56)

I can give you some perspective on this, because I've just finished converting several macOS forge projects from Trac to GitHub.

For the wikis, I wrote a script to export the Trac wiki pages from the database, convert the wiki formatting to HTML (using Trac's own renderer), then to GitHub-flavored Markdown using Pandoc, then some manual cleanup. None of the existing Trac wiki formatting conversion scripts I found were usable because they did not accommodate the entire range of Trac wiki formatting possibilities.

For the tickets, I wrote a script to convert everything from Trac tickets to GitHub issues, again converting the Trac formatting through HTML to GfM with Pandoc; converting Trac ticket type, priority, severity, resolution, and keywords to GitHub issue labels; and converting Trac user email addresses to GitHub usernames. This conversion is somewhat more lossy, as certain data can't be imported to GitHub issues, for example who reported the ticket, and GitHub issues does not support custom fields.

I did not preserve the editing history of the wiki pages, only the current versions. In fact we decided not to use wiki pages at all on GitHub, but to convert the wiki pages to web pages hosted on GitHub Pages using Jekyll and Twitter Bootstrap. But it would have been just as easy to have them be wiki pages on GitHub.

You can see the results at https://www.macosforge.org/, specifically the ALAC, Calendar and Contacts Server, Darwinbuild, Filesystem Tools, Grand Central Dispatch, SCAP on Apple and Smart Card Services projects.

Another macOS forge project, MacPorts, decided the loss of data and functionality associated with switching to GitHub issues was too great, and that the search features of GitHub issues were too limiting, so MacPorts will be staying with Trac for issues and wiki, while still moving its source code to GitHub. This move is still in progress. MacPorts has unique issue tracker requirements, because it is a package management system containing over 10,000 packages, so it needs to be easy to find tickets that relate to a specific package, hence the need for a custom field in which to specify that, and the ability to search on it. The Buildbot project might not find these limitations to be a problem.