[GHC DevOps Group] The future of Phabricator

[Simon Marlow]

What about the wiki? Can we migrate that off Trac too?

We'd have to keep redirects in place on ghc.haskell.org to avoid breaking
links to tickets and wiki pages from elsewhere.

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.

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?

Cheers
Simon

On Tue, 30 Oct 2018 at 19:22, Ben Gamari <ben at well-typed.com> wrote:

> Simon Marlow <marlowsd at gmail.com> writes:
>
> > I'm entirely happy to move, provided (1) whatever we move to provides the
> > functionality we need, and (2) it's clearly what the community wants
> > (considering both current and future contributors). In the past when
> moving
> > to GitHub was brought up, there were a handful of core contributors who
> > argued strongly in favour of Phabricator, do we think that's changed? Do
> we
> > have any indication of whether the survey respondents who were
> > anti-Phabricator would be pro- or anti-GitLab?
> >
> The comments fell into several buckets:
>
>  a. Those who spoke in favor of GitHub in particular
>  b. Those who spoke in favor of GitHub and GitLab
>  c. Those who spoke against Phabricator
>
> I seem to recall that (a) was the largest group. No one explicitly
> stated that they would be against GitLab, although this is not terribly
> surprising given we didn't ask.
>
> Frankly I doubt there would be people who would actively support GitHub
> but not GitLab given how similar the workflows are. However, collecting
> data for this hunch is one of the reasons for this thread.
>
> > Personally I'd like to optimise for more code review, because I think
> that
> > more than anything else will increase quality and community ownership of
> > the project. If using new tooling will make code review a more central
> part
> > of our workflow, then that would be a good thing.
>
> Agreed, currently we have too few reviewers for the volume of code we
> are pushing into the tree.
>
> > Right now I think we're
> > very Trac-centric, and the integration between Trac and Phabricator isn't
> > great; if we could move to a solution with tighter integration between
> > tickets/code-review/wiki, that would be an improvement in my view. But
> not
> > GitHub, for the reasons you gave.
> >
> Yes, I agree. Currently I spend too much time keeping tickets in sync and
> this is almost entirely wasted time.
>
>
> > Would GitLab solve the CI issues? I don't think you mentioned that
> > explicitly.
> >
> It helps, yes. As Andres pointed out, Appveyor has native support for
> GitLab, which we use for Windows validation. Furthermore, GitLab's
> native CI would allow us to test non-x86 platforms.
>
> CircleCI lacks GitLab support however I believe the integration we have
> already developed to support integration with Phabricator could be
> easily adapted for GitLab.
>
> Moreover, given that the "Add GitLab support" request is at the top of
> CircleCI's feature request tracker, it seems likely that there will be
> native support in the future.
>
> Cheers,
>
> - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20181102/41313e89/attachment.html>