[GHC DevOps Group] The future of Phabricator

[Simon Marlow]

For those of us that like to upload code for review without having to go to
a website and click buttons, it looks like there's this CLI tool for GitLab:

  https://github.com/zaquestion/lab

Unfortunately it's written in Go. But I guess that's an improvement over
PHP :)

Cheers
Simon


On Sat, 3 Nov 2018 at 16:35, Ben Gamari <ben at well-typed.com> wrote:

> Simon Marlow <marlowsd at gmail.com> writes:
>
> > On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel <hvriedel at gmail.com>
> > wrote:
> >
> >> On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote:
> >>
> >> > 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.
> >> [..]
> >>
> >> Well, if MRs are to be squashed on merge anyway, I'm definitely not
> >> going to waste my time carefully grooming a stack of atomic individually
> >> validating commits via git-rebase-interactive...
> >>
> >
> > Sorry I wasn't very clear. We would *only* squash if the author had been
> > using the workflow where they add commits to revise the MR. If the author
> > wants to use the stacked-diff-like workflow where they keep a groomed set
> > of commits in the MR, then we would rebase and fast-forward the MR.
> >
> > My concern here is that we have two different workflows. People used to
> > GitHub would want to use one, and people used to Phabricator would want
> to
> > use the other. We have to check which workflow people are using so that
> we
> > can decide whether to squash on merge or not.
> >
> Ahh, yes, I see.
>
> > Ben said:
> >
> >> 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.
> >
> > but that doesn't fully address the problem, because the series of commits
> > that would get rebased onto master would include all the commits added to
> > the MR to update it during the review process. Actually what we wanted to
> > do in this case was squash, not rebase+fast-forward.
> >
> Indeed, this is a problem that we already have in the case of GitHub
> pull requests. In most of these cases I end up squashing the branch
> myself when I merge (in practice this contributes very little overhead;
> I need to merge GitHub PR's myself anyways as we cannot use GitHub's
> merge button since github.com:ghc/ghc is merely a mirror of
> git.haskell.org:ghc).
>
> Of course, if we start taking *all* of our patches via MRs then I agree
> that this may become a bit more tiresome.
>
> > If there was a nice way to guide people into using the Phabricator-style
> > workflow, I think that would help a lot.
> >
> I think this is primarily a social problem and consequently it is
> probably best handled by a combination of documentation (both in the
> contributor documentation and the MR template text) and code review.
>
> One of the things I would like to do in the near future is consolidate
> (and, in some cases, rewrite) our contributor documentation. The survey
> indicated that there is plenty of room for improvement here. In this
> past we have discussed improving in this area but lacked the bandwidth
> to give the task the attention it deserves. I think now we are in better
> shape to resource it sufficiently.
>
> Cheers,
>
> - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181106/a9e044cf/attachment.html>