Herbert Valerio Riedel writes:

On 2018-10-30 at 00:54:42 -0400, Ben Gamari wrote:

...

TL;DR. For several reasons I think we should consider alternatives to Phabricator. My view is that GitLab seems like the best option.

Hello everyone,

Over the past year I have been growing increasingly weary of our continued dependence on Phabricator. Without a doubt, its code review interface is the best I have used. However, for a myriad of reasons I am recently questioning whether it is still the best tool for GHC's needs.

TL;DR. IMO, Phabricator is still the best tool we know about for *GHC's needs* ;-)

[...]

...

For one, at this point we have no options for support in the event that something goes wrong as the company responsible for Phabricator, has closed their support channels to non-paying customers.

While it's certainly a good idea to have an emergency plan ready, I don't think we need to act prematurely before something has actually happened. Phabricator is open-source and therefore there's little that can go so catastrophically wrong that we wouldn't give us more than enough time to act upon.

My point is that we have already had more than one issue that has cost significant time to resolve. Most recent is the Harbormaster issue, which lead to me having to drop everything to fix Harbormaster, which broke as a result of merging Hadrian [1]. I spent an hour trying to identify the issue and another hour trying to find a workaround before deciding to give up and just try deploying the CircleCI/Phabricator bridge that we had waiting to be deployed. Unfortunately, I then encountered another Harbormaster bug [2], which I still haven't worked out. After a couple of hours of scratching my head at this one I took to writing this email. [1] Harbormaster attempts to reuse working directories but does an inadequate job of cleaning stale submodules. This results in the any post-merge builds failing at `git checkout`. [2] Harbormaster "Send HTTP Request" build step nondeterministically resets connections after receiving valid responses, failing with the less-than-descriptive error message of "HTTP 28". I still have no idea why.

(Also, there's still the option of becoming part of that paying-customers group and thus influence their focus -- after all, we'd be contributing to a improving an OSS codebase; and not a proprietary closed product such as GitHub)

At this point I'm not convinced that the benefits that Phabricator brings us are worth the significant expense that doing this would incur, especially.

...

Furthermore, in the past year or two Phacility has been placing their development resources in the parts their customers pay them for, which appear to be much different that the parts that we actively use. For this reason, some parts that we rely on seem oddly half-finished.

This concern was recently underscored by some rather unfortunate misfeatures in Harbormaster which resulted in broken CI after the Hadrian merge and now apparent bugs which have made it difficult to migrate to the CircleCI integration we previously prepared.

Perhaps most importantly, in our recent development priorities survey our use of Phabricator was the most common complaint by a fair margin, both in case of respondents who have contributed patches and those who have not. On the whole, past contributors and potential future contributors alike have strongly indicated that they want a more Git-like experience. Of course, this wasn't terribly surprising; this is just the most recent case where contributors have made this preference known.

Frankly, in a sense it is hard to blame them. The fact that users need to install a PHP tool, Arcanist, to contribute anything but documentation patches has always seemed like unnecessary friction to me and I would be quite happy to be rid of it.

[...]

...

Indeed we have had a quite healthy number of GitHub documentation patches since we started accepting them.

While I do agree that Phabricator's impedance mismatch with Git idioms has bugged me ever since we started using it (I even started implementing https://github.com/haskell-infra/arc-lite as a proof of concept but ran out of time), I still consider some of its features unparalleled in PR-based workflows as provided by GitHub or GitLab.

For example, to me the support for stacked diffs outweights any subjective inconvenience brought forward against Phabricator

While I agree that stacked diffs are fantastic (I have used this feature often) and without match in the PR model, there are two problems with this argument: 1. In practice they are rarely used in GHC's case. There are a few reasons for this: * many patches are really a single atomic change or otherwise too small to benefit from * contributors are often unaware of the feature, typically coming from a PR-centric model * maintaining (more specifically, rebasing) stacks of differentials is a real headache with arcanist, which leaves the entirety of the work to be performed manually by the user. This is a serious problem since long-lived, large patches are precisely when you want to use a stack. * Phabricator's CI model doesn't properly account for stacking (e.g. test the patch by applying each patch in succession to the base commit), meaning the manual steps described above don't even get properly checked by CI. 2. With a slight change in thinking it's possible to get most of the benefit under a PR model. Namely, consider a PR to be a stack of differentials, with each commit being an atomic change in that stack. I have started using this model in another GHC-related project I have been working on and it works quite well, especially since GitLab has good support for reviewing commit-by-commit.

https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/?fbclid=IwAR3JyQ...

The PR workflow is perfectly well-suited for trivial documentation patches to a project; but that's for contributions that frankly are of minor importance; they're surely nice to have, but they're not the kind of contributions that are essential to GHC's long-term sustainability IMO.

The reality IMO is that everybody tends to come up with this or that complaint about a tool which isn't their favorite one, but it's hardly a real barrier to contribution. In fact, I bet the majority of the people that now complain about phabricator not being GitHub will be vocally unhappy about having to create a GitLab account and that GitLab is not GitHub...

Indeed this is true; I fully suspect that even if we did move away from Phabrictor there would still be detractor to whatever tool we choose. However, I do expect that number to be a drastic reduction from the number of we hear complaints about Phabricator. Moveover, given the number of documentation contributions that materialized since we started accepting pull requests I am hopeful that a reduction in on-boarding friction will lead to an uptick in larger contributions as well. No doubt it won't be as large as the uptick in documentation contributions, but I think there is a non-zero number of potential contributors who can do useful things around the compiler who are currently scared away by Phabricator.

Sure, by not trying to make everyone (specifically non-MVP contributors) happy we might loose some typo fixes or whatever, but do we really want to optimize the workflows for casual drive-by contributors which may contribute a couple of trivial patches and then never be seen again, at the expense of making life harder for what is already a complex enough task: managing and reviewing complex patches to GHC where it's paramount to use the best possible code-review facilities, and not shift the cost from contributors to the even more important people, the ones maintaing the projects as well as having intimate knowledge about the internals of GHCs (but unfortunately have a very tight time & cognitive time budget to spend on GHC, and which are the ones we really want to be able to review those patches with as little cognitive overhead as possible.

My point is that in my experience GitLab's review experience has been close enough to Phabricator's functionality that it hasn't affected my review productivity too much on patches of significant size. There are of course things I miss in Phabricator: * MRs are still an approximation of stacked diffs * Differential's ability to leave comment on lines untouched by the patch under review On the other hand, GitLab has features that Phabricator lacks, * the ability to merge a MR after CI finishes * Merge-after-CI-finishes

So yes, phabricator is optimized for reviewers, and that's IMO a very good thing and outweights the benefit of trying to bend over backwards to make as many contributors as possible happy, of which there are orders of magnitudes more than there GHC maintainers&experts.

I really don't view this as a matter of optimising for contributors over reviewers. As someone who does a significant amount of reviewing I have found GitLab to be good enough. It isn't as aenemic as GitHub and has gained most of the features that makes Differential usable (namely, reasonable preservation of context in the face of rebasing, the ability to diff iterations of an MR, a file tree interface to orient yourself in a large patch during review, intelligent highlighting of differences within a line, and transactional reviews). In practice I've not found myself in terrible want for anything in particular when doing review on GitLab. Cheers, - Ben

Gitlab has built-in CI support. This means it's well-integrated. I would expect the CI to improve. On Tue, Oct 30, 2018, 10:08 Simon Marlow wrote:

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?

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. 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.

Would GitLab solve the CI issues? I don't think you mentioned that explicitly.

Cheers Simon

On Tue, 30 Oct 2018 at 04:54, Ben Gamari wrote:

...

TL;DR. For several reasons I think we should consider alternatives to Phabricator. My view is that GitLab seems like the best option.

Hello everyone,

Over the past year I have been growing increasingly weary of our continued dependence on Phabricator. Without a doubt, its code review interface is the best I have used. However, for a myriad of reasons I am recently questioning whether it is still the best tool for GHC's needs.

# The problem

There are a number of reasons why I am currently uncertain about Phabricator.

For one, at this point we have no options for support in the event that something goes wrong as the company responsible for Phabricator, Phacility, has closed their support channels to non-paying customers. Furthermore, in the past year or two Phacility has been placing their development resources in the parts their customers pay them for, which appear to be much different that the parts that we actively use. For this reason, some parts that we rely on seem oddly half-finished.

This concern was recently underscored by some rather unfortunate misfeatures in Harbormaster which resulted in broken CI after the Hadrian merge and now apparent bugs which have made it difficult to migrate to the CircleCI integration we previously prepared.

Perhaps most importantly, in our recent development priorities survey our use of Phabricator was the most common complaint by a fair margin, both in case of respondents who have contributed patches and those who have not. On the whole, past contributors and potential future contributors alike have strongly indicated that they want a more Git-like experience. Of course, this wasn't terribly surprising; this is just the most recent case where contributors have made this preference known.

Frankly, in a sense it is hard to blame them. The fact that users need to install a PHP tool, Arcanist, to contribute anything but documentation patches has always seemed like unnecessary friction to me and I would be quite happy to be rid of it. Indeed we have had a quite healthy number of GitHub documentation patches since we started accepting them. This makes me thing that there may indeed be potential contributoes that we are leaving on the table.

# What to do

With Rackspace support ending at the end of year, now may be a good time to consider whether we really want to continue on this road. Phabricator is great at code review but I am less and less certain that it is worth the maintenance uncertainty and potential lost contributors that it costs.

Moreover, good alternatives seem closer at-hand than they were when we deployed Phabricator.

## Move to GitHub

When people complain about our infrastructure, they often use GitHub as the example of what they would like to see. However, realistically I have a hard time seeing GitHub as a viable option. Its feature set is simply insufficient enough to handle the needs of a larger project like GHC without significant external tooling (as seen in the case of Rust-lang).

The concrete reasons have been well-documented in previous discussions but, to summarize,

* its review functionality is extremely painful to use with larger patches

* rebased patches lead to extreme confusion and lost review comments

* it lacks support for pre-receive hooks, which serve as a last line of defense to prevent unintended submodule changes

* its inability to deal with external tickets is problematic

* there is essentially no possibility that we could eventually migrate GHC's tickets to GitHub's ticket tracker without considerable data loss (much less manage the ticket load that would result), meaning that we would forever be stuck with maintaining Trac.

* on a personal note, its search functionality has often left me empty-handed

On the whole, these issues seem pretty hard to surmount.

## Move to GitLab

In using GitLab for another project over the past months I have been positively surprised by its quality. It handles rebased merge requests far better than GitHub, has functional search, and quite a usable review interface. Furthermore, upstream has been extremely responsive to suggestions for improvement [1]. Even out-of-the-box it seems to be flexible enough to accommodate our needs, supporting integration with external issue trackers, having reasonable release management features, and support for code owners to automate review triaging (replacing much of the functionality of Phabricator's Herald).

Finally, other FOSS projects' [3] recent migrations from Phabrictor to GitLab have shown that GitLab-the-company is quite willing to offer help when needed. I took some time this weekend to try setting up a quick GHC instance [2] to play around with. Even after just a few hours of playing around I think the result is surprisingly usable.

Out of curiosity I also played around with importing some tickets from Trac (building on Matt Pickering's Trac-to-Maniphest migration tool). With relatively little effort I was even able to get nearly all of our tickets (as of 9 months ago) imported while preserving ticket numbers (although there are naturally a few wrinkles that would need to be worked out). Naturally, I think we should treat the question of ticket tracker migration as an orthogonal one to code review, but it is good to know that this is possible.

## Continue with Phabricator

Continuing with Phabricator is of course an option. Its review functionality is great and it has served us reasonably well. However, compared to GitLab and even GitHub of today its features seem less distinguished than they once did. Moreover, the prospect of having to maintain a largely stagnant product with no support strikes me as a slightly dangerous game to play. Working around the issues we have recently encountered has already cost a non-negligible amount of time.

# The bottom line

If it wasn't clear already, I think that we should strongly consider a move to GitLab. At this point it seems clear that it isn't going to vanish, has a steady pace of development, is featureful, and available.

However, these are just my thoughts. What do you think?

Cheers,

- Ben

[1] 11.4 will ship with a file tree view in the code review interface, which I reported (https://gitlab.com/gitlab-org/gitlab-ce/issues/46474) as being is one of the Phabricator features I missed the most during review

[2] https://gitlab.home.smart-cactus.org/ghc/ghc/issues/14641

[3] The GNOME and freedesktop.org projects have recently migrated, the former from a hodge-podge of self-hosted services and the latter from Phabricator

_______________________________________________ Ghc-devops-group mailing list Ghc-devops-group@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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 wrote:

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

Imants Cekusins writes:

Are other alternatives being considered?

I generally focused on GitHub and GitLab as these are the two options that are widely used in the open-source community and received the most attention in our survey results.

You may find these examples relevant:

TFS https://visualstudio.microsoft.com/tfs/ (Git repos is an option)

It seems the server requires a Windows machine to run. I consider this to be an immediate dealbreaker.

Atlassian https://www.atlassian.com/

I have worked with Atlassian products in the past and have not found them to be convenient to use. Furthermore, neither of these options are open source, which raises some serious lock-in concerns. Cheers, - Ben

Once you rebase you simply move the branch pointer to a new chain of commits (they're rewritten because of the rebase, and thus have different hashes), however the old version of the branch still exists in the reflog. So locally you can definitely see your previous versions of your 'commit stack' by just pointing the branch pointer to the old commit hash or checking out that commit hash directly. However as far as I'm aware neither GitHub and gitlab expose this in their UI. On Fri, Nov 2, 2018, 09:59 Herbert Valerio Riedel

On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote:

...

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

I worry that it's a lot of work to migrate it away while preserving the special markup and features that Trac provides; so the resulting pages will require a significant amount of manual cleanup and finding ways to emulate the previous features; for instance, I've been using features like https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes a lot as they allow to highlight important information and footnote-like annotations in; and thus IMO help contribute to present the information less wall-of-text-ish which is harder to digest.

[...]

...

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.

(Minor nitpick: in GitLab there are no pull-requests (PRs) anymore; they're called "MRs" for "merge-request", which is probably a more accurate term to describe the concept than "PR" is)

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...

...

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.

...submitting a stacked set of commits as invidual overlapping MRs (i.e. where the first MR has only the first commit, the 2nd has the first two commits from the stack, and so on) -- if that's what you're referring to as "Phabricator-style" -- sounds like an awkward workflow to 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?

I wonder too how this is represented in GitLab... especially when a MR is comprised of multiple commits, and those individual commits evolve, might get reordered, commits added or removed fromt he stack, or when the whole MR gets rebased in the process... _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Herbert Valerio Riedel writes:

On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote:

...

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

I worry that it's a lot of work to migrate it away while preserving the special markup and features that Trac provides; so the resulting pages will require a significant amount of manual cleanup and finding ways to emulate the previous features; for instance, I've been using features like https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes a lot as they allow to highlight important information and footnote-like annotations in; and thus IMO help contribute to present the information less wall-of-text-ish which is harder to digest.

[...]

...

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.

(Minor nitpick: in GitLab there are no pull-requests (PRs) anymore; they're called "MRs" for "merge-request", which is probably a more accurate term to describe the concept than "PR" is)

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...

...

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.

...submitting a stacked set of commits as invidual overlapping MRs (i.e. where the first MR has only the first commit, the 2nd has the first two commits from the stack, and so on) -- if that's what you're referring to as "Phabricator-style" -- sounds like an awkward workflow to me.

Right this is not the workflow I would advocate. Rather, just submit a single MR with your atomic changes represented as commits. In fact, this is already what I do locally when preparing stacked Phabricator differentials (to put another way, one commit == one differential). GitLab has good support for reviewing commit-by-commit.

...

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?

I wonder too how this is represented in GitLab... especially when a MR is comprised of multiple commits, and those individual commits evolve, might get reordered, commits added or removed fromt he stack, or when the whole MR gets rebased in the process...

To be clear, GitLab saves each head commit that you push to an MR branch. These iterations are known in the review interface as "versions". The review interface then allows you to view differences between either a. any two versions b. any version and the target branch (e.g. master) Unfortunately (but perhaps not unexpectedly) this scheme does not deal well with changes due to a change in base commit (as would happen in the case of rebasing). It appears that GitLab must just run `git diff` between the two heads when asked to compare two versions of a MR. Cheers, - Ben

On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel 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...

This shouldn't be a problem. One can easily configure a project such

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. Ben said: 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. If there was a nice way to guide people into using the Phabricator-style workflow, I think that would help a lot. Cheers Simon

...

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.

...submitting a stacked set of commits as invidual overlapping MRs (i.e. where the first MR has only the first commit, the 2nd has the first two commits from the stack, and so on) -- if that's what you're referring to as "Phabricator-style" -- sounds like an awkward workflow to 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?

I wonder too how this is represented in GitLab... especially when a MR is comprised of multiple commits, and those individual commits evolve, might get reordered, commits added or removed fromt he stack, or when the whole MR gets rebased in the process... _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Nov 3, 2018, at 9:17 AM, Alan & Kim Zimmerman wrote:

As part of the silent bystander grouping, I just want to voice a weak ok for switching to gitlab,

+1 to this exact sentiment from me, and for the same reasons Alan voiced. I have a horse in this race and care about the outcome, but don't have enough of an informed opinion to really say anything of substance. I'm very grateful to those who have informed opinions and will debate (and then implement) our way into the future. Richard

Simon Marlow writes:

On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel 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

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

I’ve found that GitHub encourages git commits as a project journal even though gits originating prject has a very diff / change set oriented workflow. And The latter is a more useful granularity of contribution for complex prjects like ghc. On Sun, Nov 4, 2018 at 10:27 AM Manuel M T Chakravarty wrote:

...

Am 30.10.2018 um 10:07 schrieb Simon Marlow :

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?

FWIW, while I still think GitHub is preferable, GitLab would be an improvement over Phabricator IMHO.

Cheers, Manuel

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Hi Ben, On Tue, 30 Oct 2018 at 15:34, Ben Gamari wrote:

...

Some of the issues I list with GitHub are entirely orthogonal to GitHub's code review tool.

While Rust has shown that large open-source projects can use GitHub, they have also demonstrated that it requires a remarkable amount of automation.

Could you say more about how this would affect GHC? The issues with GitHub that were listed in your original email are all to do with reviews (and to my knowledge addressed by layering reviewable.io on top of GitHub as Manuel says), except a couple. Cribbing from followup emails as well, I end up with the following list: * Poor integration with external issue trackers (or at any rate with Trac), I assume meaning, hard to transactionally close issues upon PR merge and other ticket status updates. * No merge-on-green-CI button. So keeping the review UX issues aside for a moment, are there other GitHub limitations that you anticipate would warrant automation bots à la Rust-lang? I'm not too worried about the CI story. The hard part with CircleCI isn't CircleCI, it's getting to a green CircleCI. But once we're there, moving to a green OtherCI shouldn't be much work. Best, Mathieu

Hi Ben, On Tue, 30 Oct 2018 at 18:47, Ben Gamari wrote:

...

It occurs to me that I never did sit down to write up my thoughts on reviewable. I tried doing a few reviews with it [1] and indeed it is quite good; in many ways it is comparable to Differential. [...] However, it really feels like a band-aid, introducing another layer of indirection and a distinct conversation venue all to make up for what are plain deficiencies in GitHub's core product.

Sure. That sounds fine to me though, or indeed no different than say, using GitHub XOR Gitlab for code hosting, Phabricator for review (and only for that), and Trac for tickets (not ideal but no worse than status quo). If Phabricator (the paid for hosted version) or Reviewable.io really are the superior review tools, and if as review tools they integrate seamlessy with GitHub (or Gitlab), then that's an option worth considering. The important things are: reducing the maintenance burden (by preferring hosted solutions) while still meeting developer requirements and supporting a workflow that is familiar to most.

...

So keeping the review UX issues aside for a moment, are there other GitHub limitations that you anticipate would warrant automation bots à la Rust-lang?

Ultimately Rust's tools all exist for a reason. Bors works around GitHub's lacking ability to merge-on-CI-pass, Highfive addresses the lack of a flexible code owner notification system, among other things. Both of these are features that we either have already or would like to have.

... and I assume based on your positive assessment, are both out-of-the-box features of Gitlab that meet the requirements?

On the whole, I simply see very few advantages to using GitHub over GitLab; the latter simply seems to me to be a generally superior product.

That may well be the case. The main argument for GitHub is taking advantage of its network effect. But a big part of that is not having to manage a new set of credentials elsewhere, as well as remembering different user names for the same collaborators on different platforms. You're saying I can use my GitHub credentials to authenticate on Gitlab. So in the end we possibly wouldn't be losing much of that network effect.

...

I'm not too worried about the CI story. The hard part with CircleCI isn't CircleCI, it's getting to a green CircleCI. But once we're there, moving to a green OtherCI shouldn't be much work.

Right, and we are largely already there!

That's great to hear.

Michal Terepeta writes:

Hope you don't mind if I add an opinion of a small/occasional contributor to the thread.

Personally, I would prefer a move to GitHub. Mostly due to familiarity and network effect (pretty much everyone is on GitHub).

But I would also consider a move to GitLab a big improvement over the current Phab-based setup. A git-based workflow would be great - I use arc/Phab too rarely to really invest in learning them better. (I just figured out the simplest way to use them that seems to work and I'm sticking to it :) I haven't actually used GitLab before, but it seems super easy to sign in using GitHub credentials and the interface seems quite familiar.

One thing that was already mentioned is the ticket handling and I just wanted to say "+1". I *really* dislike Trac - it's slow, unintuitive and every time I use it I need to spend a couple of minutes to find the guide to its own weird version of markdown... So a better place for tickets that's tightly integrated with code code hosting/review tools would be really cool! Which brings an interesting aspect of this discussion - if I had to choose between "GitHub for code hosting/review & Trac for tickets" vs "GitLab for everything", I'd prefer the latter.

Thanks for this data point, Michal! Cheers, - Ben

For what it’s worth, I’ve never found phab / arc to be the bottle neck / actual time consuming piece of doing anything for ghc It’s defintely the nicest code review substrate I’ve engaged with One question I have : how does the llvm org manage / handle their phabricator instance and or ci substrate. Maybe they have wisdom that can help ? On Thu, Nov 1, 2018 at 7:27 PM Vladislav Zavialov wrote:

To put my 2¢ – I will be happy with whatever service provides the most reliable CI.

In terms of workflow, I like Ben's suggestion:

* Consider a PR to be a stack of differentials, with each commit being an atomic change in that stack. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

"Boespflug, Mathieu" writes:

Hi Ben,

On Tue, 30 Oct 2018 at 18:47, Ben Gamari wrote:

...

The important things are: reducing the maintenance burden (by preferring hosted solutions) while still meeting developer requirements and supporting a workflow that is familiar to most.

Right; I believe that GitLab checks all of these boxes.

...

Ultimately Rust's tools all exist for a reason. Bors works around GitHub's lacking ability to merge-on-CI-pass, Highfive addresses the lack of a flexible code owner notification system, among other things. Both of these are features that we either have already or would like to have.

... and I assume based on your positive assessment, are both out-of-the-box features of Gitlab that meet the requirements?

Yes, GitLab has support for both of these features natively.

...

On the whole, I simply see very few advantages to using GitHub over GitLab; the latter simply seems to me to be a generally superior product.

That may well be the case. The main argument for GitHub is taking advantage of its network effect. But a big part of that is not having to manage a new set of credentials elsewhere, as well as remembering different user names for the same collaborators on different platforms. You're saying I can use my GitHub credentials to authenticate on Gitlab. So in the end we possibly wouldn't be losing much of that network effect.

Precisely, GitLab supports OAuth authentication, so one can login with GitHub credentials. Cheers, - Ben

In one sense our migration was prescient, on the other hand i really wish gitlab had a more performant code review ux. Are there any performant for large code review tools? I find the reload rendering latency and auto collapse defaults in gitlab pretty painful and I’m pretty ignorant of the land scape these days. On Fri, Sep 17, 2021 at 7:27 PM Niklas Hambüchen via ghc-devs < ghc-devs@haskell.org> wrote:

For those interested:

Three years later, Phabricator shut down.

May 29, 2021:

https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_ope...

On 10/30/18 5:54 AM, Ben Gamari wrote:

...

For one, at this point we have no options for support in the event that something goes wrong as the company responsible for Phabricator, Phacility, has closed their support channels to non-paying customers. Furthermore, in the past year or two Phacility has been placing their development resources in the parts their customers pay them for, which appear to be much different that the parts that we actively use. For this reason, some parts that we rely on seem oddly half-finished.

---

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs