These plans seem awfully ambitious, but I look forward to them.
Ok. Well, we'll take it one step at a time; it's my expectation that each step by itself is manageable.
Depending on the difficulty, I think I would rather just migrate all
of my Trac stuff to gitlab instead of trying to make Trac work with gitlab in some fashion. (Unless gitlab and Trac already have some kind of integration.)
Well, if you're up to writing CL code to do the migration, I think it's doable:
** Wiki - Raw documents can be dowloaded from Trac, so if you have a list of pages to download, you can simply run those through cURL/wget. (URL format: https://trac.common-lisp.net/cmucl/wiki/GitAndCmucl?format=txt) - it looks like [http://johnmacfarlane.net/pandoc/ PanDoc] is your way to go for the conversion of the wiki format - I'm working on a cl-gitlab library which can be used to connect to the gitlab API and upload wiki documents
Hmm. come to think of it, you probably want to migrate the wiki into a local repository and push them to the server as described here: https://gitlab.com/gitlab-org/omnibus-gitlab/wikis/git_access
** Tickets - Tickets can be downloaded in one big XML document (URL: https://trac.common-lisp.net/cmucl/login?referer=%2Fcmucl%2Freport%2F11%3Fas... ) - After extracting the above URL, cl-gitlab can be used to create the milestones used in the extract - cl-gitlab can be used to (re)create the tickets from trac, where I suggest to move these fields to the body text - Not all fields available on Trac are available in the GitLab tracker; i'd propose adding them to the ticket's body; specifically: Reporter and Version - Fields "Priority" and "Component" can be transformed into Labels (a kind of "tags") - Successive comments should be uploaded as comments/notes; this can be done using cl-gitlab as well.
Note that both the wiki and the tickets can use Wiki markup in Trac as well as GitLab, so every text body (comment, wiki page or ticket) probably needs to be run through pandoc.
If there are more projects that want/need such conversion, we'd probably best try to share any efforts automating the process.