[GHC DevOps Group] The future of Phabricator

[Ben Gamari]

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 --------------
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/20181103/127874a5/attachment.sig>