bug#34889: [RFE] Migration to gitlab

bug#34889: [RFE] Migration to gitlab

[Konstantin Kharlamov]

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

Re: [RFE] Migration to gitlab

[Konstantin Kharlamov]

В Вс, мар 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

bug#34889: [RFE] Migration to gitlab

[Konstantin Kharlamov]

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 
<hi-angel@yandex.ru> написал:
> 
> 
> В Вс, мар 17, 2019 at 5:17 ДП (AM), Konstantin Kharlamov 
> <hi-angel@yandex.ru> написал:
>> I want to start by answering first likely question: the Community 
>> \x7fEdition of gitlab should be fine license-wise, quoting Richard 
>> \x7fStallman "We have a simple way of looking at these two versions. 
>> The \x7ffree 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 
>> \x7fthat better could've been implemented in core. It's a lot of 
>> \x7fcontributors out there; at the same time, I see very little patches 
>> \x7fon emacs-devel list.
>> 
>> A lot of open-source projects already migrated to gitlab: all 
>> \x7fFreeDesktop projects, all Gnome projects; and KDE are likely to 
>> \x7fmigrate soon too². Gnome reports: "After switching to GitLab, I 
>> \x7fnoticed almost immediately an increase in contributions from people 
>> I \x7fhadn’t met before. I think GitLab really lowered the threshold 
>> for \x7fpeople getting started"³.
>> 
>> So, at the very least, migrating to gitlab should make contributions 
>> \x7feasier for bigger part of the open-source world, peoples who used 
>> to \x7fgithub and gitlab. (btw, here's a rarely mentioned point, why in 
>> \x7fparticular mailing-list workflow is hard for newcomers: almost 
>> every \x7fmail client out there breaks formatting by default; and 
>> configuring \x7fthat out isn't always easy).
>> 
>> Other points include:
>> 	1. I know some people like to operate with mails rather than 
>> \x7fweb-interface (which is what usual gitlab workflow based on). For 
>> \x7fthem gitlab can be configured to be managed with mails. I don't 
>> know \x7fhow far it stretches, but at the very least creating/replying 
>> to \x7fissues/merge requests can be enabled.⁴
>> 	2. Gitlab makes addressing review comments easier. With mailing 
>> \x7flists workflow you either need to α) send a v2 of the patch; which 
>> \x7fis a little frustrating: you need to find message-id to feed it to 
>> \x7fgit-send-email, and then you need to make sure its title lines up 
>> \x7fwith the rest of the series. Or β) resend whole patch-series; 
>> which \x7fcan be just redundant when all you did was a one-line change, 
>> and \x7fclutters the mailing list. Also, upon sending v3, v4, etc. you 
>> need \x7fto save somewhere changes since v1. You can put it in actual 
>> commits, \x7fbut for git-history this information is unnecessary. With 
>> gitlab \x7fworkflow, on the other hand, you just force-push changes to 
>> the \x7fbranch that has merge-request opened. A single command, that it.
>> 	3. CI. I've recently seen someone on emacs-devel⁵ asking a 
>> \x7fcontributor to run their syntax-checking script on a regular basis. 
>> \x7fThat's becase you can't run any check on a code hanging out there 
>> on \x7fa mailing list in pure air. Gitlab supports CI, i.e. one can set 
>> it \x7fup to run unit-tests for every merge-request created, so these 
>> errors \x7fget caught before getting to the tree; and possibly even 
>> before \x7fgetting to eyes of reveiwers.
>> 	4. Impossible to lose "merge request". I've seen in Emacs docs an 
>> \x7fadvice to send patch series to a bugtracker, because on emacs-devel 
>> \x7fthey can easily be forgotten. That can't happen so easily with 
>> \x7fgitlab, where you have a tab with open merge requests.
>> 	5. Discussion on patch series is easier to read. On mailing lists 
>> \x7fcan quickly appear a dozen of no longer relevant review mails, that 
>> \x7frefer to something that was addressed. In Gitlab the addressed 
>> \x7fcomments can be marked as such, and get collapsed.
>> 	6. More tightly integrated bugtracker. When a commit refers to an 
>> \x7fissue, it can be seen from inside the issue. This is useful e.g. 
>> when \x7fsomeone fixed a problem, but for some reason couldn't address 
>> review \x7fcomments, leaving the code behind. Then later peoples who 
>> stumble \x7fupon the same issue can just improve the code instead of 
>> doing \x7fresearch and writing it on their own.
>> 	7. Unclear how to download a patch-series from mailing list. 
>> Usually \x7fmailing-list driven projects add some system that tracks 
>> patches, and \x7fallows to download series. E.g. that's how Mesa 
>> worked. But Emacs \x7fdon't seem to have one. With gitlab though you 
>> can simply fetch \x7fsomeone's branch.
>> 
>> 1: 
>> \x7fLINKIFYdbAIfbAJCFEdBdcaGafeAeDbfbHBCEdbHCJHIcBb
>> 2: 
>> \x7fLINKIFYfDdcICIaccAJGDDIfIEfBBeEdeCCEFIeGcGBAdBD
>> 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
> 
> 
> 

bug#34889: [RFE] Migration to gitlab

[Eli Zaretskii]

tags 34889 notabug
thanks

I'm closing this because it is not a bug.  Please continue the
discussion on emacs-devel, but please don't cross-post to the bug
tracker.

bug#34889: [RFE] Migration to gitlab

[Konstantin Kharlamov]

Hmm, okay, but then where feature-requests supposed to go?

В Вс, мар 17, 2019 at 6:39 ДП (AM), Eli Zaretskii 
<eliz@gnu.org> написал:
> tags 34889 notabug
> thanks
> 
> I'm closing this because it is not a bug.  Please continue the
> discussion on emacs-devel, but please don't cross-post to the bug
> tracker.

Re: [RFE] Migration to gitlab

[Philippe Vaucher]

[-- Attachment #1: Type: text/plain, Size: 2301 bytes --]

>
> 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"³.
>

I agree. I contribute often on github/gitlab, and the process is very
simple. In comparison, Emacs has hurdles that requires much more motivation
and persistance in order to contribute.

I think it boils down to this: on github/gitlab, almost everything is
handled by git itself: you propose/test changes by creating/pulling
branches on the repository/fork... so you basically only need to use git
and click a few buttons in the browser (or use magithub/emacs-gitlab etc).
With the Emacs model, you need to go back & forth between emails and git,
copying patches, applying them, keeping track of where each changes is,
etc. The extra step does not look like much but it is a lot, especially for
simple changes.



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

Yeah, the maintainer job is easier, no need to remember which topics are
the active ones. Searching for existing or past similar issues also feels
simpler, but I guess that is just habit.



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

It's also easier to view the current states of the commits, you don't need
to search for the latest patch in the list of emails.

Now, the Emacs model is similar to the linux kernel dev & the git dev
workflow, so obviously "it works fine" and has advantages too, but
personally I think those are outweighted by the the disadvantages (or
rather than the contribution experience is much nicer with gitlab).

Kind regards,
Philippe

[-- Attachment #2: Type: text/html, Size: 3053 bytes --]

bug#34889: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Sun, 17 Mar 2019 07:04:57 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 34889-done@debbugs.gnu.org
> 
> Hmm, okay, but then where feature-requests supposed to go?

Requests to add features to Emacs should indeed be sent to the
tracker.  But you were raising an issue with the Emacs development
process, not with the Emacs software.  So the proper place to discuss
what you wanted is on emacs-devel.

Re: [RFE] Migration to gitlab

[Eric Abrahamsen]

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/