|
From: | Tim Cross |
Subject: | Re: [RFE] Migration to gitlab |
Date: | Sun, 17 Mar 2019 19:20:57 +1100 |
Oops. Please, reply to this mail, I haven't thought that mails to
bugs-gnu gonna create new reports. Fixed here.
В Вс, мар 17, 2019 at 6:01 ДП (AM), Konstantin Kharlamov
<address@hidden> написал:
>
>
> В Вс, мар 17, 2019 at 5:17 ДП (AM), Konstantin Kharlamov
> <address@hidden> написал:
>> 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
>
>
>
[Prev in Thread] | Current Thread | [Next in Thread] |