[GHC DevOps Group] The future of Phabricator

[Ben Gamari]

Simon Marlow <marlowsd at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181102/b54f5a5e/attachment.sig>