Thanks! Were you able to do anything to preserve existing Trac URLs? Dustin
2016-09-27 14:13 GMT-04:00 Ryan Schmidt <[email protected]>: > > > On Sep 27, 2016, at 12:14 PM, Dustin J. Mitchell <[email protected]> > 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. > > >
_______________________________________________ users mailing list [email protected] https://lists.buildbot.net/mailman/listinfo/users
