
Moving to GitLab - sahin-boydas
https://mail.haskell.org/pipermail/ghc-devs/2018-December/016613.html
======
judge2020
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/01...](https://mail.haskell.org/pipermail/ghc-
devs/2018-November/016457.html)

~~~
the_common_man
Does anyone know what did not work out with phabricator?

~~~
meestaplu
Ben Gamari's October 30 email ([https://mail.haskell.org/pipermail/ghc-
devs/2018-October/016...](https://mail.haskell.org/pipermail/ghc-
devs/2018-October/016425.html)) 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
> 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

~~~
lugg
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/Advance...](https://mediawiki.org/wiki/Special:MyLanguage/Gerrit/Advanced_usage)

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

------
chx
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-initia...](https://www.drupal.org/drupalorg/blog/developer-tools-
initiative-part-5-gitlab-partnership)

And it's coming
[https://groups.google.com/a/association.drupal.org/forum/#!t...](https://groups.google.com/a/association.drupal.org/forum/#!topic/changes/ZTYUEParS5U)

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

~~~
cercatrova
Then the Department of Justice will step in and it'll be 2001 all over again

------
sytelus
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
What is wrong with Travis compared to GL's default CI?

~~~
jhasse
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
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
I want to run my build/test commands in a Docker image.

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

------
noneucat
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
thx, fixed the title

------
RomanPushkin
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
I thought Phabricator was open source?

~~~
penagwin
Same with gitlab? (They're self hosting an instance)

~~~
vignesh_m
there are some features in pro version, but yeah its mostly open source

~~~
zuron7
Afaik, The Pro version is open source as well, it's just not usable without a
key.

~~~
jimktrains2
That's not really possible, and I'm not sure what you mean.

~~~
mikewhy
They may be referring to this: [https://gitlab.com/gitlab-org/gitlab-
ee](https://gitlab.com/gitlab-org/gitlab-ee)

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

~~~
PurpleRamen
Classic ML sucks, and gitlab is opensource that can be selfhosted. The world
evolved and offers now better environments than 20 years ago. No reason to
stay behind.

~~~
u801e
> Classic ML sucks

Could you elaborate on why that is? The git and linux kernel projects have
been using this workflow for decades and it works very well for them.

> The world evolved and offers now better environments than 20 years ago.

I think that's largely subjective. I have experience reviewing code via email
and via a Github Enterprise instance.

The Github based review requires far more scrolling and makes it difficult to
find comments that were made and how they were resolved. Plus, it makes the
implicit assumption that a comment was resolved if the line commented on was
changed in any way regardless of whether or not the change is related to the
comment made. When that happens, it collapses the comment thread and requires
that I expand them to find out what I commented on and determine whether it
was addressed by going to another tab to read through the entire diff, find
the approximate location of the line I commented on and see if it was changed
as I expected.

With the email based workflow, my email client has a built in index of all the
comments made on a patch set threaded by commit that I can click on and I can
quickly find the comments I made and any responses to them (and whether or not
I've already read them). I can easily get different versions of the patch set
and run a diff between them to see what changed (either on the entire diff or
on each individual commit).

> The world evolved and offers now better environments than 20 years ago. No
> reason to stay behind.

I believe that if something should be considered an improvement, then it
should have all the capabilities of the previous version and introduce new
features that were not possible to accomplish in the previous version. It
shouldn't make things that were easy to do in the previous version more
difficult or impossible to do.

~~~
avar
Not the GP, but I contribute to the Git project. I think your some of your
critique of GitHub Enterprise is correct (although don't you need to also
"resolve discussion" if the lines change, or is that just GitLab?), just
commenting on the "why not ML" aspect of this.

> With the email based workflow, my email client has a built in index of all
> the comments made[...]

The reason for why E-Mail based workflows like those used by Linux and Git
didn't win over "just host on Git(Hub|Lab)" is because this requires a lot of
setup & technical expertise from your contributors that just using a web UI
gives you out of the box.

Right off the bat you need to have been subscribed to the list for a
significant amount of time to do what you're describing, or if you're lucky
(e.g. in the case of the Git project) use some E-Mail archive[1]. You're
already looking at maybe a week of setup time for someone who's never used
E-Mail in this way (which applies for most devs these days) just to get to the
point you'd get in 10 seconds with a search box on GitHub or GitLab.

Does it pay off in a lot of ways? Sure, but at the cost of losing a lot of
potential contributors. It's not a big deal for projects like linux.git or
git.git whose contributors are by definition at the tail end of the competency
curve when it comes being comfortable with setting up this sort of thing, but
good luck running e.g. some popular WordPress plugin this way.

1\. [https://public-inbox.org/git/](https://public-inbox.org/git/)

~~~
u801e
> although don't you need to also "resolve discussion" if the lines change, or
> is that just GitLab?

I believe Github recently deployed a feature to do just that, but that hasn't
made it over to the enterprise version. In either case, it's something that's
been a source of problems for quite a few years.

> Right off the bat you need to have been subscribed to the list for a
> significant amount of time to do what you're describing

That's one inherent limitation with email lists. Fortunately, both public-
inbox and gmane provide a NNTP gateway to allow for access to list archives
with an interface that's, for all practical purposes, identical to email.

As an aside, I've always wondered why open source projects like git and linux
never adopted NNTP (not necessarily on usenet) as a primary form of
communication (and and email CC contributers of code that you're changing)
instead of using an email list.

> this requires a lot of setup & technical expertise from your contributors
> [...] You're already looking at maybe a week of setup time

I simply don't see how it requires significant expertise or a week to set up.
Using a client like Thunderbird for reading the list (or NNTP gateway) doesn't
take that much to set up (other than entering the server information and
credentials to send replies). Setting up one's git configuration for using
git-send-email (to send patches) is only a one time thing as well and isn't
any more complex.

Years ago, ISPs commonly provided help pages that gave the server information
to set up your client to access one's email account hosted on the ISP and how
to access the NNTP server to get on usenet. You didn't need significant
technical expertise to follow the instructions on those pages and many non-
technical people successfully configured their clients to receive/send their
email and participate on usenet newsgroups.

~~~
avar
> I simply don't see how it requires significant expertise or a week to set
> up[...]

I don't just mean the setup required to send a one-off patch. Obviously
setting up some random E-Mail client with IMAP is easy. But the sort of setup
required to get anything like feature parity with common operations in
GitHub's or GitLab's interface.

E.g. when you open a Pull/Merge request on those sites. It's easy to apply &
download the patch series locally to test it. For E-Mail client integration
you need something that'll "git am" a range of messages. Likewise with "git
push" to your topic branch updating the PR/MR. Sure you can do this all
manually with git-format-patch and git-send-email, but having something that
works smoothly takes a lot of work.

And nowadays the network effects of that setup don't make sense for most
contributors, because so few projects still use E-Mail like this. There's a
large long tail of contributors to these projects, e.g. the median for patches
in git.git per contributor is 2.

~~~
u801e
> when you open a Pull/Merge request on those sites. It's easy to apply &
> download the patch series locally to test it. For E-Mail client integration
> you need something that'll "git am" a range of messages.

That's a good point. Like git-am is the inverse of git-format-patch.
Unfortunately, no program has been written as the corresponding inverse of
git-send-email. If a program like that existed, then one could get feature
parity.

At least with Thunderbird, one can highlight the messages one wants to save
and save them to multiple files in a folder.

> Likewise with "git push" to your topic branch updating the PR/MR. Sure you
> can do this all manually with git-format-patch and git-send-email, but
> having something that works smoothly takes a lot of work.

Based on what I've read, people typically rebase their patch series and push
up a new set of emails as a reply to the original patch series. In
Github/Gitlab, people typically make an incremental commit and push it up.

But, if one wants to maintain a clean commit history for a given feature
development branch before it's merged, one will have to rebase and apply those
incremental commits to their corresponding base commit. That's trivial if the
feature is implemented in a single commit, but a bit more complex if it's
multiple commits. The former case has been addressed by Github with their
squash before merge feature I believe. The latter case requires manual
rebasing (which arguably is more more than just doing it locally before
pushing up the next version of the patch set).

~~~
xte
Hem, notmuch/mu4e offer easy magit integration so you can see, test, patch etc
straight from a mail messages... That's the power of a text-centric UI vs a
graphical-centric UI.

~~~
u801e
I'll try it out. vim is my main editor, so it will be a bit of a learning
curve to get used to emacs :)

As an aside, I have tried out gnus for reading the git mailing list via gmane,
but I found it very slow in threading messages (when compared to Thunderbird).
I don't know if notmuch/mu4e has the same issue though.

