8 ms·

Moving to GitLab

189 points by sahin 8y ago

noneucat 8y ago
I don't recall GHC development ever being on GitHub? Most I can find is a mirror at https://github.com/ghc/ghc https://github.com/ghc/ghc. edit: Title has been changed.
- sahin-boydas 8y ago
  thx, fixed the title
judge2020 8y ago
Note: this is about moving from Phabricator to GitLab, not GitHub to GitLab. GHC Discussion from November about moving to GitLab/moving away from Phabricator: https://mail.haskell.org/pipermail/ghc-devs/2018-November/016457.html https://mail.haskell.org/pipermail/ghc-devs/2018-November/01...
- deleted 8y ago
  [deleted]
- the_common_man 8y ago
  Does anyone know what did not work out with phabricator?
  - meestaplu 8y ago
    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...
RomanPushkin 8y ago
What's the point of moving from one proprietary service to another? One day GetLab will get acquired by another tech giant, or will stay the same - it doesn't matter too much, because it's already owned by private company and venture capitalists. They do what they want, and they definitely won't turn down million-dollar acquisition offer.
- bbody 8y ago
  I thought Phabricator was open source?
  - penagwin 8y ago
    Same with gitlab? (They're self hosting an instance)
    - vignesh_m 8y ago
      there are some features in pro version, but yeah its mostly open source
      - zuron7 8y ago
        Afaik, The Pro version is open source as well, it's just not usable without a key.
        jimktrains2 8y ago
        That's not really possible, and I'm not sure what you mean.
        mikewhy 8y ago
        They may be referring to this: https://gitlab.com/gitlab-org/gitlab-ee https://gitlab.com/gitlab-org/gitlab-ee
        gyaru 8y ago
u801e 8y ago
Was a move to Gerrit or the email patch workflow ever discussed?
xte 8y ago
A small note: what's the difference between GitLab, GitHub etc? Are they companies with a substantially identical target: making money? Does they offer storage on their own server (or even worse others servers in a chain)? So why the hell instead of moving from a company to another ANY FOSS dev do not came back to classic ML (mirrored offline in personal maildir) and use hosting, multiple if possible, only as a mean to offer a shared repo? Why not even serve the project via the repo itself like fossil? There is a world outside the web, on our desktops. Just as a suggestion: try to disconnect your desktop and look what you can or can't do. If you feel "empty" you are in danger.
- saagarjha 8y ago
  The reason people put their code online is because it is a convenient way to host it, and often platforms like these have some ancillary tools that make the code easy to work with.
  - xte 8y ago
    Yep for simply putting it on-line, but using platform features like GitHub pull-request, wikis, pages etc means voluntary tie to a platform. If I only use Git{Hub,Lab}, Phabricator, ... as a repo host no problem, I can change as I want.
  - u801e 8y ago
    There's nothing in the classic mailing list workflow that prevents hosting the code online for others to view. The Linux[1] and git[2] projects mirror their code on Github, for example. [1] https://github.com/torvalds/linux https://github.com/torvalds/linux [2] https://github.com/git/git https://github.com/git/git
- unixhero 8y ago
  Gitlab also runs locally.
  - brodock 8y ago
    We also provide an Export tarball with everything inside you project, including the repo, issues, merge request content, etc. We do not lock you up in a walled garden. It's also easy to import the whole project/group from one instance to another.
sytelus 8y ago
TLDR; Why GitLab instead of GitHub? From their discussion group thread: - Good multi-platform hosted CI or at least workable integration with other (existing) CI solutions - Hosted review tool that we don't have to maintain ourselves (though a little bit less good than Phabricator, allegedly) - familiar GitHub-like workflow with no requirement to install extra software locally - Reuse of GitHub credentials - Realistic path forward for migrating tickets from Trac CI is becoming Achilles heels for GitHub. Personally I would probably also add lack of fine grained permissions for contributors, inflexible diff, very basic code review tool as well.
- wodenokoto 8y ago
  What is wrong with Travis compared to GL's default CI?
  - jhasse 8y ago
    Does Travis have native Docker support? Last time I checked you had to manually run docker and add "sudo: true" to your .travis.yml.
    - http-teapot 8y ago
      I am not exactly sure of your use case but we build our Docker images in Travis without problems. https://docs.travis-ci.com/user/docker/ https://docs.travis-ci.com/user/docker/
      - jhasse 8y ago
        I want to run my build/test commands in a Docker image.
  - rleigh 8y ago
    Travis is limited. Stuff like this https://gitlab.com/codelibre/ome-model/pipelines/37267293 https://gitlab.com/codelibre/ome-model/pipelines/37267293 is several steps beyond the capabilities of Travis. This is using platforms not supported by Travis, plus custom Docker images. And integrates with other GitLab pipelines, deploys to sonatype nexus, and stores artifacts for later use. Even if you're not using the advanced features, it's still vastly better than Travis. The Travis stock images are so out of date it's not funny.
chx 8y ago
Notably Drupal is also moving to GitLab. It's over 40 000 projects, it's not easy. Announcement was at https://www.drupal.org/drupalorg/blog/developer-tools-initiative-part-5-gitlab-partnership https://www.drupal.org/drupalorg/blog/developer-tools-initia... And it's coming https://groups.google.com/a/association.drupal.org/forum/#!topic/changes/ZTYUEParS5U https://groups.google.com/a/association.drupal.org/forum/#!t...
ksec 8y ago
Gitlab seems to fit all the Open Source Project ideals and philosophy. They don't want the burden of managing a dozen difference software or services for their development, they want coding, not time messing with Ops. And it has to be Open Source and no lock it. And Gitlab could even host it for you with with out you having the hassle. Amazon, Google. One of them likely to acquire Gitlab. Strategically speaking both company would be a great fit for Gitlab, the only problem is both company absolutely loathe Ruby and Rails. Or there could be another slim possibility, Microsoft decide to Open Source Github Core.
- app4soft 8y ago
  > Or there could be another slim possibility, Microsoft decide to Open Source Github Core Or there could be another slim possibility, Microsoft decide to acquire GitLab...
  - preommr 8y ago
    "slim possibility" If Microsoft was dumb enough to pay 7+ bn for Github, there's probably a good chance they'd do something stupid again and bust out another fat stack of billions for Gitlab.
  - cercatrova 8y ago
    Then the Department of Justice will step in and it'll be 2001 all over again
- bad_user 8y ago
  Generally speaking when software companies get acquired, the product dies. If a company is being bought by a bigger company, it only means that the profits aren’t good enough for that company to go public, while at the same time a return is owed to its investors. It means that the company played loose with other people’s money and selling the company is the way out. In other words companies that are sold are companies that are struggling. And if that’s the case, the product itself will struggle to generate profits post acquisition as well. And I think there aren’t many examples that are an exception to this rule. We certainly see YouTube or Instagram flourishing as a result of scale. But those are the exception. GitHub was sold because GitHub wasn’t profitable or hype-driven enough to go public. It remains to be seen if GitHub survives. But back to a potential acquisition of GitLab, if it ever happens, I believe GitLab will die, with a community fork being the only way out. I’m writing this because HN has a fetish for acquisitions, which is interesting since to me an acquisition is often a death announcement.

189 points by sahin 8y ago

I don't recall GHC development ever being on GitHub? Most I can find is a mirror at https://github.com/ghc/ghc https://github.com/ghc/ghc. edit: Title has been changed.

sahin-boydas 8y ago
thx, fixed the title

judge2020 8y ago

Note: this is about moving from Phabricator to GitLab, not GitHub to GitLab. GHC Discussion from November about moving to GitLab/moving away from Phabricator: https://mail.haskell.org/pipermail/ghc-devs/2018-November/016457.html https://mail.haskell.org/pipermail/ghc-devs/2018-November/01...

deleted 8y ago
[deleted]
the_common_man 8y ago
Does anyone know what did not work out with phabricator?
- meestaplu 8y ago
  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...

RomanPushkin 8y ago

What's the point of moving from one proprietary service to another? One day GetLab will get acquired by another tech giant, or will stay the same - it doesn't matter too much, because it's already owned by private company and venture capitalists. They do what they want, and they definitely won't turn down million-dollar acquisition offer.

bbody 8y ago
I thought Phabricator was open source?
- penagwin 8y ago
  Same with gitlab? (They're self hosting an instance)
  - vignesh_m 8y ago
    there are some features in pro version, but yeah its mostly open source
    - zuron7 8y ago
      Afaik, The Pro version is open source as well, it's just not usable without a key.
      - jimktrains2 8y ago
        That's not really possible, and I'm not sure what you mean.
        mikewhy 8y ago
        They may be referring to this: https://gitlab.com/gitlab-org/gitlab-ee https://gitlab.com/gitlab-org/gitlab-ee
        gyaru 8y ago

u801e 8y ago

Was a move to Gerrit or the email patch workflow ever discussed?

xte 8y ago

A small note: what's the difference between GitLab, GitHub etc? Are they companies with a substantially identical target: making money? Does they offer storage on their own server (or even worse others servers in a chain)? So why the hell instead of moving from a company to another ANY FOSS dev do not came back to classic ML (mirrored offline in personal maildir) and use hosting, multiple if possible, only as a mean to offer a shared repo? Why not even serve the project via the repo itself like fossil? There is a world outside the web, on our desktops. Just as a suggestion: try to disconnect your desktop and look what you can or can't do. If you feel "empty" you are in danger.

saagarjha 8y ago
The reason people put their code online is because it is a convenient way to host it, and often platforms like these have some ancillary tools that make the code easy to work with.
- xte 8y ago
  Yep for simply putting it on-line, but using platform features like GitHub pull-request, wikis, pages etc means voluntary tie to a platform. If I only use Git{Hub,Lab}, Phabricator, ... as a repo host no problem, I can change as I want.
- u801e 8y ago
  There's nothing in the classic mailing list workflow that prevents hosting the code online for others to view. The Linux[1] and git[2] projects mirror their code on Github, for example. [1] https://github.com/torvalds/linux https://github.com/torvalds/linux [2] https://github.com/git/git https://github.com/git/git
unixhero 8y ago
Gitlab also runs locally.
- brodock 8y ago
  We also provide an Export tarball with everything inside you project, including the repo, issues, merge request content, etc. We do not lock you up in a walled garden. It's also easy to import the whole project/group from one instance to another.

sytelus 8y ago

TLDR; Why GitLab instead of GitHub? From their discussion group thread: - Good multi-platform hosted CI or at least workable integration with other (existing) CI solutions - Hosted review tool that we don't have to maintain ourselves (though a little bit less good than Phabricator, allegedly) - familiar GitHub-like workflow with no requirement to install extra software locally - Reuse of GitHub credentials - Realistic path forward for migrating tickets from Trac CI is becoming Achilles heels for GitHub. Personally I would probably also add lack of fine grained permissions for contributors, inflexible diff, very basic code review tool as well.

wodenokoto 8y ago
What is wrong with Travis compared to GL's default CI?
- jhasse 8y ago
  Does Travis have native Docker support? Last time I checked you had to manually run docker and add "sudo: true" to your .travis.yml.
  - http-teapot 8y ago
    I am not exactly sure of your use case but we build our Docker images in Travis without problems. https://docs.travis-ci.com/user/docker/ https://docs.travis-ci.com/user/docker/
    - jhasse 8y ago
      I want to run my build/test commands in a Docker image.
- rleigh 8y ago
  Travis is limited. Stuff like this https://gitlab.com/codelibre/ome-model/pipelines/37267293 https://gitlab.com/codelibre/ome-model/pipelines/37267293 is several steps beyond the capabilities of Travis. This is using platforms not supported by Travis, plus custom Docker images. And integrates with other GitLab pipelines, deploys to sonatype nexus, and stores artifacts for later use. Even if you're not using the advanced features, it's still vastly better than Travis. The Travis stock images are so out of date it's not funny.

chx 8y ago

Notably Drupal is also moving to GitLab. It's over 40 000 projects, it's not easy. Announcement was at https://www.drupal.org/drupalorg/blog/developer-tools-initiative-part-5-gitlab-partnership https://www.drupal.org/drupalorg/blog/developer-tools-initia... And it's coming https://groups.google.com/a/association.drupal.org/forum/#!topic/changes/ZTYUEParS5U https://groups.google.com/a/association.drupal.org/forum/#!t...

ksec 8y ago

Gitlab seems to fit all the Open Source Project ideals and philosophy. They don't want the burden of managing a dozen difference software or services for their development, they want coding, not time messing with Ops. And it has to be Open Source and no lock it. And Gitlab could even host it for you with with out you having the hassle. Amazon, Google. One of them likely to acquire Gitlab. Strategically speaking both company would be a great fit for Gitlab, the only problem is both company absolutely loathe Ruby and Rails. Or there could be another slim possibility, Microsoft decide to Open Source Github Core.

app4soft 8y ago
> Or there could be another slim possibility, Microsoft decide to Open Source Github Core Or there could be another slim possibility, Microsoft decide to acquire GitLab...
- preommr 8y ago
  "slim possibility" If Microsoft was dumb enough to pay 7+ bn for Github, there's probably a good chance they'd do something stupid again and bust out another fat stack of billions for Gitlab.
- cercatrova 8y ago
  Then the Department of Justice will step in and it'll be 2001 all over again
bad_user 8y ago
Generally speaking when software companies get acquired, the product dies. If a company is being bought by a bigger company, it only means that the profits aren’t good enough for that company to go public, while at the same time a return is owed to its investors. It means that the company played loose with other people’s money and selling the company is the way out. In other words companies that are sold are companies that are struggling. And if that’s the case, the product itself will struggle to generate profits post acquisition as well. And I think there aren’t many examples that are an exception to this rule. We certainly see YouTube or Instagram flourishing as a result of scale. But those are the exception. GitHub was sold because GitHub wasn’t profitable or hype-driven enough to go public. It remains to be seen if GitHub survives. But back to a potential acquisition of GitLab, if it ever happens, I believe GitLab will die, with a community fork being the only way out. I’m writing this because HN has a fetish for acquisitions, which is interesting since to me an acquisition is often a death announcement.