Re: [RFE] Migration to gitlab

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> В Вс, мар 17, 2019 at 5:17 ДП (AM), Konstantin Kharlamov
> <hi-angel@yandex.ru> написал:
>> 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
>
> Btw, one more point I just got: no more discrepancy between what
> mailing list subscribers see, and what web-interface renders. E.g. the
> nicely formatted list of points above from the outside worls looks
> like a large single line:
> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00531.html

Not to muddy the waters further, but Source Hut (or Sir Hat) is a newish
"forge" that seems very much in line with Emacs' aesthetic, and provides
extensive integration with mailing lists. Might be a nice middle ground.

https://man.sr.ht/