Simon Marlow <marlo...@gmail.com> writes: > 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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
