Simon Marlow
What about the wiki? Can we migrate that off Trac too?
Yes, we certainly can. As Herbert mentioned, some of the fancier markup in Trac will require a bit of manual grooming. However, the basic idea is easily implemented with the migration that I already developed.
We'd have to keep redirects in place on ghc.haskell.org to avoid breaking links to tickets and wiki pages from elsewhere.
Yes, absolutely.
If we really can do a stacked-diff-style workflow using PRs on GitLab then that at least for me removes one of the big drawbacks of moving. But how easy will it be to enforce that workflow and will it be going against the grain on GitLab? I imagine people used to adding extra commits to a PR will tend to do that rather than amending+rebasing. I suppose we can do a squash-merge when committing to keep the history clean, but then contributors have a choice - either do GitHub-style where you add commits to a PR to update it and we squash on merge, OR Phabricator-style where you keep the same set of commits and rebase the stack to update it. If you want to do dependent commits then you have to use Phabricator style. Choices between workflows make things more complicated for contributors, and that worries me.
This shouldn't be a problem. One can easily configure a project such that users are *only* allowed to fast-forward/rebase, disallowing the creation of merge commits.
Does GitLab keep the history of a PR after it has been updated, like in Phabricator? So we can see what happened between versions of a PR?
Yes it does. Cheers, - Ben