[devel at bb.net] [users at bb.net] Weekly Meeting Notes
Dustin J. Mitchell
dustin at buildbot.net
Thu Sep 29 02:14:29 UTC 2016
Thanks! Were you able to do anything to preserve existing Trac URLs?
2016-09-27 14:13 GMT-04:00 Ryan Schmidt <buildbot at ryandesign.com>:
> > On Sep 27, 2016, at 12:14 PM, Dustin J. Mitchell <dustin at buildbot.net>
> > 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,
> > • 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel