I want to start by answering first likely question: the Community
Edition of gitlab should be fine license-wise, quoting Richard
Stallman "We have a simple way of looking at these two versions.
The free version is free software, so it is ethical."¹
Terms: "merge request" in gitlab means "patch series sent for
review".
----
It makes me sad, seeing Emacs addons popping up, for a functional
that better could've been implemented in core. It's a lot of
contributors out there; at the same time, I see very little patches
on emacs-devel list.
A lot of open-source projects already migrated to gitlab: all
FreeDesktop projects, all Gnome projects; and KDE are likely to
migrate soon too². Gnome reports: "After switching to GitLab, I
noticed almost immediately an increase in contributions from people
I hadn’t met before. I think GitLab really lowered the threshold
for people getting started"³.
So, at the very least, migrating to gitlab should make contributions
easier for bigger part of the open-source world, peoples who used
to github and gitlab. (btw, here's a rarely mentioned point, why in
particular mailing-list workflow is hard for newcomers: almost
every mail client out there breaks formatting by default; and
configuring that out isn't always easy).
Other points include:
1. I know some people like to operate with mails rather than
web-interface (which is what usual gitlab workflow based on). For
them gitlab can be configured to be managed with mails. I don't
know how far it stretches, but at the very least creating/replying
to issues/merge requests can be enabled.⁴
2. Gitlab makes addressing review comments easier. With mailing
lists workflow you either need to α) send a v2 of the patch; which
is a little frustrating: you need to find message-id to feed it to
git-send-email, and then you need to make sure its title lines up
with the rest of the series. Or β) resend whole patch-series;
which can be just redundant when all you did was a one-line change,
and clutters the mailing list. Also, upon sending v3, v4, etc. you
need to save somewhere changes since v1. You can put it in actual
commits, but for git-history this information is unnecessary. With
gitlab workflow, on the other hand, you just force-push changes to
the branch that has merge-request opened. A single command, that it.
3. CI. I've recently seen someone on emacs-devel⁵ asking a
contributor to run their syntax-checking script on a regular basis.
That's becase you can't run any check on a code hanging out there
on a mailing list in pure air. Gitlab supports CI, i.e. one can set
it up to run unit-tests for every merge-request created, so these
errors get caught before getting to the tree; and possibly even
before getting to eyes of reveiwers.
4. Impossible to lose "merge request". I've seen in Emacs docs an
advice to send patch series to a bugtracker, because on emacs-devel
they can easily be forgotten. That can't happen so easily with
gitlab, where you have a tab with open merge requests.
5. Discussion on patch series is easier to read. On mailing lists
can quickly appear a dozen of no longer relevant review mails, that
refer to something that was addressed. In Gitlab the addressed
comments can be marked as such, and get collapsed.
6. More tightly integrated bugtracker. When a commit refers to an
issue, it can be seen from inside the issue. This is useful e.g.
when someone fixed a problem, but for some reason couldn't address
review comments, leaving the code behind. Then later peoples who
stumble upon the same issue can just improve the code instead of
doing research and writing it on their own.
7. Unclear how to download a patch-series from mailing list.
Usually mailing-list driven projects add some system that tracks
patches, and allows to download series. E.g. that's how Mesa
worked. But Emacs don't seem to have one. With gitlab though you
can simply fetch someone's branch.
1:
https://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00095.html
2:
http://kde.6490.n7.nabble.com/Gitlab-Evaluation-amp-Migration-td1708416.html
3: https://www.gnome.org/news/2018/05/gnome-moves-to-gitlab-2/
4: https://docs.gitlab.com/ee/administration/incoming_email.html
5:
http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00131.html