5 ms·

Ben Gamari's October 30 email (https://mail.haskell.org/pipermail/ghc-devs/2018-October/016425.html https://mail.haskell.org/pipermail/ghc-devs/2018-October/016

Ben Gamari's October 30 email (https://mail.haskell.org/pipermail/ghc-devs/2018-October/016425.html https://mail.haskell.org/pipermail/ghc-devs/2018-October/016...) to the ghc-devs list proposed considering alternatives to Phabricator and outlines reasons that Phab wasn't working. A summary of the problems outlined in the email: * Lack of options for support from Phacility * Free/open source components of Phabricator feeling half-finished because Phacility has redirected development resources to paid features * Issues with Harbormaster (Phabricator's half-baked CI system) * Developer's prefer using regular Git to Phabricator's nonstandard workflow, which requires installation of the Arcanist command-line tool (written in PHP to manage patches.

edoceo 8y ago
> Phabricator's nonstandard workflow, which requires installation of the Arcanist command-line tool I was just going to eval Phab for my team, your comment identified a deal breaker for us and you've saved me more than a few wasted hours. Thank you
- munchor 8y ago
  I am actually a big fan of Arcanist. It rather simplifies the Git workflow management. You simply develop new code in a separate branch from master, and use `arc diff` from said branch to start a Pull Request (called a "diff" in the Arc world). No need to use `git push` and manage upstream branches, simply rely on the diff abstraction. It has many great features including `arc diff --preview` which gives you a link to a preview of your PR so you can see what it looks like in the browser (much better than `git diff`). Of course, there is a bit of a learning curve and most engineers already know the standard git workflow. That is a disadvantage of course, but only in the short term. If it's a short project, then I would recommend against it. However, if you're in it for the long run, arc is great. I feel like the other points (CI, lack of support, etc.) much better show the weak points of Phabricator versus GitHub or GitLab.
- lima 8y ago
  Phabricator's nonstandard workflow and tooling is one of its distinct advantages - maybe give it a second thought.
- lugg 8y ago
  Please ignore the others in this thread. Phabricator is basically cancer. I'm partial to Gerrit if you're looking for a git native solution with branch, draft, patch, review, iterate workflows with proper merge/rebase handling. It is a bit different from "GitHub flow" but mostly a big improvement in an organisation context (vs FOSS.) Media wiki has the best docs but it's a bit dense. https://mediawiki.org/wiki/Gerrit https://mediawiki.org/wiki/Gerrit This page below has a decent graphic and lots of quick examples to show you how powerful it is to work with git instead of gimping it with a wrapper. https://mediawiki.org/wiki/Special:MyLanguage/Gerrit/Advanced_usage https://mediawiki.org/wiki/Special:MyLanguage/Gerrit/Advance...
  - skrebbel 8y ago
    > Phabricator is basically cancer. I think you need a lessen in sensible writing. You don't like Phabricator, fine. It's not cancer. Not "basically" either.
    - lugg 8y ago
      You don't like my casual use of the word cancer? Fine. Personally I feel like cancer was a relatively good approximation for the cancerous like changes you need to make to established industry workflows once you begin to use phabricator. Would you have preferred I used the word infection? Virus? Aids? Which one of those metaphors crosses the "sense writing" line for you? Why does cancer?
      - barneygale 8y ago
        Describing software as "cancer" is something I'd expect to see on 4chan or reddit, not HN. It's hyperbole and your explanation ("relatively good approximation for the cancerous like changes [to] workflows") shows as much.
        deleted 8y ago
        [deleted]
- IshKebab 8y ago
  Arcanist is actually a reasonably nice tool. It is certainly far superior to opening pull requests in a web interface. The only real downside I've found with using phabricator at work is the lack of a decent built in CI system. You can integrate it with external ones fairly well but that seems like something you shouldn't have to do.
lima 8y ago
> Free/open source components of Phabricator feeling half-finished because Phacility has redirected development resources to paid features There are no closed-source Phabricator components. The email is complaining about development focus being on the wrong parts (the ones paying customers use), rather the ones Haskell uses.

edoceo 8y ago

> Phabricator's nonstandard workflow, which requires installation of the Arcanist command-line tool I was just going to eval Phab for my team, your comment identified a deal breaker for us and you've saved me more than a few wasted hours. Thank you

munchor 8y ago
I am actually a big fan of Arcanist. It rather simplifies the Git workflow management. You simply develop new code in a separate branch from master, and use `arc diff` from said branch to start a Pull Request (called a "diff" in the Arc world). No need to use `git push` and manage upstream branches, simply rely on the diff abstraction. It has many great features including `arc diff --preview` which gives you a link to a preview of your PR so you can see what it looks like in the browser (much better than `git diff`). Of course, there is a bit of a learning curve and most engineers already know the standard git workflow. That is a disadvantage of course, but only in the short term. If it's a short project, then I would recommend against it. However, if you're in it for the long run, arc is great. I feel like the other points (CI, lack of support, etc.) much better show the weak points of Phabricator versus GitHub or GitLab.
lima 8y ago
Phabricator's nonstandard workflow and tooling is one of its distinct advantages - maybe give it a second thought.
lugg 8y ago
Please ignore the others in this thread. Phabricator is basically cancer. I'm partial to Gerrit if you're looking for a git native solution with branch, draft, patch, review, iterate workflows with proper merge/rebase handling. It is a bit different from "GitHub flow" but mostly a big improvement in an organisation context (vs FOSS.) Media wiki has the best docs but it's a bit dense. https://mediawiki.org/wiki/Gerrit https://mediawiki.org/wiki/Gerrit This page below has a decent graphic and lots of quick examples to show you how powerful it is to work with git instead of gimping it with a wrapper. https://mediawiki.org/wiki/Special:MyLanguage/Gerrit/Advanced_usage https://mediawiki.org/wiki/Special:MyLanguage/Gerrit/Advance...
- skrebbel 8y ago
  > Phabricator is basically cancer. I think you need a lessen in sensible writing. You don't like Phabricator, fine. It's not cancer. Not "basically" either.
  - lugg 8y ago
    You don't like my casual use of the word cancer? Fine. Personally I feel like cancer was a relatively good approximation for the cancerous like changes you need to make to established industry workflows once you begin to use phabricator. Would you have preferred I used the word infection? Virus? Aids? Which one of those metaphors crosses the "sense writing" line for you? Why does cancer?
    - barneygale 8y ago
      Describing software as "cancer" is something I'd expect to see on 4chan or reddit, not HN. It's hyperbole and your explanation ("relatively good approximation for the cancerous like changes [to] workflows") shows as much.
      - deleted 8y ago
        [deleted]
IshKebab 8y ago
Arcanist is actually a reasonably nice tool. It is certainly far superior to opening pull requests in a web interface. The only real downside I've found with using phabricator at work is the lack of a decent built in CI system. You can integrate it with external ones fairly well but that seems like something you shouldn't have to do.

lima 8y ago

> Free/open source components of Phabricator feeling half-finished because Phacility has redirected development resources to paid features There are no closed-source Phabricator components. The email is complaining about development focus being on the wrong parts (the ones paying customers use), rather the ones Haskell uses.