The future of Phabricator

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

The future of Phabricator

Ben Gamari-3

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-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Herbert Valerio Riedel-3


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.

(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)

> 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

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

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

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.

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.

An interest talk in this context is

"Rebuilding the Cathedral" by Nadia Eghbal
https://www.youtube.com/watch?v=VS6IpvTWwkQ

Which makes the very point that the most important people for a
project's sustainability are its maintainers rather than their
contributors.


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Simon Marlow-7
In reply to this post by Ben Gamari-3
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 <[hidden email]> 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
[hidden email]
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Arian van Putten-2
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: The future of Phabricator

David Feuer-2
In reply to this post by Ben Gamari-3
What's to prevent GitLab from doing what Phabricator has once enough companies have committed to it?

David Feuer
Well-Typed Consultant
On Oct 30, 2018, at 12:55 AM, Ben Gamari <[hidden email]> 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-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: The future of Phabricator

Matthew Pickering
In reply to this post by Ben Gamari-3
The compelling argument against Phabricator is that (as Ben mentions)
parts of the product have remained unfinished whilst seemingly
low-priority features are worked on for months. I think at the start
Austin had a lot of success interacting with the maintainers but now
you can't make a new ticket unless you are a paying customer.

A compelling argument to move to gitlab is the possibility of tighter
integration between the patches and tickets.

I'm saying this as someone who much prefers using arcanist and the
phabricator diff model to the git PR model but at the end of the day,
everyone who contributes to GHC is able to use both models as most
projects are hosted on github.

I would be interested in reading more about the GNOME and freedesktop
switch to gitlab. In particular the technical details of the
migration.

So I fully support Ben's judgement here and hope that we can make a
decision with haste.

Cheers,

Matt
On Tue, Oct 30, 2018 at 4:55 AM Ben Gamari <[hidden email]> 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-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: The future of Phabricator

Herbert Valerio Riedel-3
On 2018-10-30 at 11:53:18 +0000, Matthew Pickering wrote:

[...]

> A compelling argument to move to gitlab is the possibility of tighter
> integration between the patches and tickets.

You don't need to move to GitLab to achieve that, do you?

In fact, we had this project where somebody invested quite a lot of time
& effort to implement a proof of concept for migrating Trac tickets into
Phabricator which you might remember; it was generally well received
but afaik this was silently forgotten about and so the ball was dropped
in pushing it further:

  https://mail.haskell.org/pipermail/ghc-devs/2016-December/013444.html

I'd much rather sacrifice Trac's benefits by consolidating Trac tickets
into Phabricator (if the tighter integration between code-review &
ticketing is the main compelling argument) than to give up on both,
Phabricator *and* Trac.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Manuel M T Chakravarty-4
In reply to this post by Ben Gamari-3
Hi Ben,

Thanks a lot for the summary of the situation.

As you know, I do dislike Phabricator for the many reasons that you are listing, and it would be nice to finally move to a better system. In particular, it is worth emphasising the fact highlighted by the survey, namely that "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.”

One the one hand, we want broader participation in GHC development; on the other hand, we constantly ignore the single largest source of frustration for contributors. That just doesn’t make a lot of sense to me, even if it can be explained by the inertia of some existing developers.

Unfortunately, if I am not mistaken, GitLab also has a big problem. It requires the use of GitLab CI — i.e., we cannot use CircleCI and Appveyor with it. (At least, that is my current understanding. Please correct me if I am wrong.)

Given that large organisations work with large code bases on GitHub, I am still puzzled why GHC somehow cannot do that. (I do understand that the dev process that has been established within GHC is naturally focused around Phabricator and its tools. However, that doesn’t mean it couldn’t be changed to work as well as before, but with another tool.)

In any case, I think, you didn’t mention one of the options we did discuss previously, namely to use GitHub together with a service that adds more sophisticated code review functionality, such as


This would solve the CI issues without further ado.

Cheers,
Manuel

Am 30.10.2018 um 05:54 schrieb Ben Gamari <[hidden email]>:


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
[hidden email]
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: The future of Phabricator

Ben Gamari-3
In reply to this post by David Feuer-2
David Feuer <[hidden email]> writes:

> What's to prevent GitLab from doing what Phabricator has once enough
> companies have committed to it?
>
In principle, nothing. However, in general GitLab-the-company seems
significantly more devoted to the idea of GitLab as an open-source
project than Phacility was to Phabricator.

In truth, Phabricator was
never really an healthy FOSS project. Yes, the source was available but
the maintainers were quite clear that they have no intention of
accepting unsolicited patches.

GitLab, on the other hand, encourages external contributors, has
actively supported adoption by open source projects and has an active
set of maintainers.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Ben Gamari-3
In reply to this post by Manuel M T Chakravarty-4
Andres Löh <[hidden email]> writes:

> Hi.
>
>> Unfortunately, if I am not mistaken, GitLab also has a big problem. It requires the use of GitLab CI — i.e., we cannot use CircleCI and Appveyor with it. (At least, that is my current understanding. Please correct me if I am wrong.)
>
> Just a clarification on this issue.
>
> I might be wrong, but my understanding is that:
>
> - Gitlab offers its own Gitlab CI, but it doesn't force you to use it,
>   and doesn't prevent you from using other CI solutions.
>
> - Web-based CI solutions have to specifically support Gitlab for you to
>   be able to use them with Gitlab.
>
> - To my knowledge, Appveyor supports Gitlab, but Circle and Travis
>   currently do not. I know that there are issues open for these systems
>   to support Gitlab, but I have no idea whether this is likely to happen
>   anytime soon. For example, for Circle, the discussion seems to be
>   here: https://circleci.com/ideas/?idea=CCI-I-248
>
That is entirely correct; however, we have already invested the effort
to build a bridge between Phabricator and CircleCI (only to have
deployment complicated by an apparent Phabricator bug).

The implementation of this didn't take particularly long and I expect
migrating this work to GitLab would be if anything easier (since GitLab
has a more-standard REST interface than Phabricator's Conduit).

Cheers,

- ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Ben Gamari-3
In reply to this post by Manuel M T Chakravarty-4
Manuel M T Chakravarty <[hidden email]> writes:

> Hi Ben,
>
...

>
> Given that large organisations work with large code bases on GitHub, I
> am still puzzled why GHC somehow cannot do that. (I do understand that
> the dev process that has been established within GHC is naturally
> focused around Phabricator and its tools. However, that doesn’t mean
> it couldn’t be changed to work as well as before, but with another
> tool.)
>
> In any case, I think, you didn’t mention one of the options we did
> discuss previously, namely to use GitHub together with a service that
> adds more sophisticated code review functionality, such as
>
>   https://reviewable.io <https://reviewable.io/>
>
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 (I counted three distinct bots in use on the first random
pull request I opened). In my own discussions with Rust-lang maintainers
they have noted that even with this tooling they are still somewhat
unhappy with the amount of manual busywork working within GitHub
requires.

More generally, I think the move to CircleCI in a way underscores why
I'm a bit hesitant to move to another silo. While it generally does
"just work", there have been several cases where I have had to have
multi-week interactions CircleCI support to work through inscrutable
build issues. Moreover, we continue to be bit by the inability to
prioritize jobs and, despite efforts, still have no ability to build for
non-Linux/amd64 platforms. Consequently I'm rather skittish about moving
to another platform where we have limited insight into issues, no
influence over direction of development, and no ability to fix bugs
where necessary.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Ben Gamari-3
In reply to this post by Herbert Valerio Riedel-3
Herbert Valerio Riedel <[hidden email]> 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=IwAR3JyQP5uCn6ENiHOTWd41y5D-U0_CCJ55_23nzKeUYTjgLASHu2dq5QCc0
>
> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Boespflug, Mathieu
In reply to this post by Ben Gamari-3
Hi Ben,

On Tue, 30 Oct 2018 at 15:34, Ben Gamari <[hidden email]> 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
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Ben Gamari-3
"Boespflug, Mathieu" <[hidden email]> writes:

> Hi Ben,
>
> On Tue, 30 Oct 2018 at 15:34, Ben Gamari <[hidden email]> 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:
>
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. It's a bit
sluggish to load (loading a moderate-sized patch took over 15 seconds in
Firefox) but after that it seems quite usable. The comment functionality
is great; the ability to leave comments even on lines that were
untouched by the patch is noted.

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.

Moreover, given that using it implies that we also need to buy in to the
other deficiencies in GitHub's core product, it's not clear to me why we
would go this direction when there are open-source, more featureful
alternatives that also have a history of being adoption by large
open-source projects. I suspect it will make little difference to
contributors; one can authenticate to both with GitHub credentials and
the UX is fairly similar. To me, the choice seems fairly clear-cut.


[1] Admittedly my these were single-shot reviews and lacked the usual
    back-and-forth that one typically has during review, but on
    moderate-size patches, so I think they are fairly representative.

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

Furthermore, we already recognize that there are holes in our current CI
story: relying on cross-compilation to validate non-Linux/amd64
architectures both complicates troubleshooting and requires that we fix
issues in GHC's build system that I would rather not tie CI to. GitLab would
allow us to potentially continue using CircleCI for "normal" platforms
while giving us the ability to easily fill this holes with GitLab's
native CI support (which I have used in a few projects; it is both easy
to configure and flexible).

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.
Furthermore, we should remember that no product will be perfect; in
light of this it is important to consider a) the openness of the
implementation, and b) the responsiveness of the upstream developer.
GitLab has the advantage of being open-source with an extremely
responsive upstream; this stands in contrast to GitHub, where I have had
straightforward pull requests [2] languish for the better part of a year
before being merged and deployed.


[2] https://github.com/github/markup/pull/925

> 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! Hadrian, Darwin, Fedora, and
Debian/amd64 builds are all currently green; i386 is hours from passing
(a regression recently snuck in which I pinned down this morning), the
LLVM build is pending a fix for a long-standing critical bug (#14251),
and we are now two tests away from slow validation being green.

The remaining piece is moving differential validation to CircleCI. This
was one of the motivations for starting this discussion.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Ben Gamari-3
In reply to this post by Simon Marlow-7
Simon Marlow <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Boespflug, Mathieu
In reply to this post by Ben Gamari-3
Hi Ben,

On Tue, 30 Oct 2018 at 18:47, Ben Gamari <[hidden email]> 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.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

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

- Michal


On Tue, Oct 30, 2018 at 10:51 PM Boespflug, Mathieu <[hidden email]> wrote:
Hi Ben,

On Tue, 30 Oct 2018 at 18:47, Ben Gamari <[hidden email]> 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.
_______________________________________________
Ghc-devops-group mailing list
[hidden email]
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Ben Gamari-3
In reply to this post by Boespflug, Mathieu
"Boespflug, Mathieu" <[hidden email]> writes:

> Hi Ben,
>
> On Tue, 30 Oct 2018 at 18:47, Ben Gamari <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Ben Gamari-2
In reply to this post by Michal Terepeta
Michal Terepeta <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] The future of Phabricator

Vladislav Zavialov-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
12