[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debbugs-tracker] bug#34889: closed ([RFE] Migration to gitlab)
From: |
GNU bug Tracking System |
Subject: |
[debbugs-tracker] bug#34889: closed ([RFE] Migration to gitlab) |
Date: |
Sun, 17 Mar 2019 03:40:03 +0000 |
Your message dated Sun, 17 Mar 2019 05:39:26 +0200
with message-id <address@hidden>
and subject line Re: bug#34889: [RFE] Migration to gitlab
has caused the debbugs.gnu.org bug report #34889,
regarding [RFE] Migration to gitlab
to be marked as done.
(If you believe you have received this mail in error, please contact
address@hidden)
--
34889: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34889
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message ---
Subject: |
[RFE] Migration to gitlab |
Date: |
Sun, 17 Mar 2019 05:17:50 +0300 |
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
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#34889: [RFE] Migration to gitlab |
Date: |
Sun, 17 Mar 2019 05:39:26 +0200 |
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.
--- End Message ---
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [debbugs-tracker] bug#34889: closed ([RFE] Migration to gitlab),
GNU bug Tracking System <=