From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.bugs,gmane.emacs.devel Subject: bug#34889: [RFE] Migration to gitlab Date: Sun, 17 Mar 2019 05:17:50 +0300 Message-ID: <1552789070.5272.1@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="169208"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel To: 34889@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 17 03:19:17 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h5LOO-000huY-DN for geb-bug-gnu-emacs@m.gmane.org; Sun, 17 Mar 2019 03:19:16 +0100 Original-Received: from localhost ([127.0.0.1]:49079 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5LON-00017O-1v for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Mar 2019 22:19:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5LOD-00017I-1O for bug-gnu-emacs@gnu.org; Sat, 16 Mar 2019 22:19:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h5LOB-000243-Io for bug-gnu-emacs@gnu.org; Sat, 16 Mar 2019 22:19:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33273) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h5LOB-00023t-DM for bug-gnu-emacs@gnu.org; Sat, 16 Mar 2019 22:19:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h5LOA-0000V1-QZ for bug-gnu-emacs@gnu.org; Sat, 16 Mar 2019 22:19:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Mar 2019 02:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 34889 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.15527890971859 (code B ref -1); Sun, 17 Mar 2019 02:19:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 17 Mar 2019 02:18:17 +0000 Original-Received: from localhost ([127.0.0.1]:46817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5LNM-0000Tp-AZ for submit@debbugs.gnu.org; Sat, 16 Mar 2019 22:18:17 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56273) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5LNJ-0000Tc-IJ for submit@debbugs.gnu.org; Sat, 16 Mar 2019 22:18:10 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:43657) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h5LNC-0001eH-1E for submit@debbugs.gnu.org; Sat, 16 Mar 2019 22:18:02 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5LNA-00014I-Qa for bug-gnu-emacs@gnu.org; Sat, 16 Mar 2019 22:18:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h5LN7-0001cf-TM for bug-gnu-emacs@gnu.org; Sat, 16 Mar 2019 22:18:00 -0400 Original-Received: from forward103p.mail.yandex.net ([77.88.28.106]:45895) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h5LN5-0001bD-R2; Sat, 16 Mar 2019 22:17:57 -0400 Original-Received: from mxback13j.mail.yandex.net (mxback13j.mail.yandex.net [IPv6:2a02:6b8:0:1619::88]) by forward103p.mail.yandex.net (Yandex) with ESMTP id E19CB18C0367; Sun, 17 Mar 2019 05:17:52 +0300 (MSK) Original-Received: from smtp2o.mail.yandex.net (smtp2o.mail.yandex.net [2a02:6b8:0:1a2d::26]) by mxback13j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id zfN0Np3XuS-HqQ4P6wZ; Sun, 17 Mar 2019 05:17:52 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1552789072; bh=tXkekbxJvAlfBh+JQX6Uzh+UfCSZZX1CE/XFHuOb3i0=; h=Cc:To:Subject:From:Date:Message-Id; b=uj7Djb13Yeyo9hoLijEl6SjbvufstfVmOkEZ6Fag3H98xPJm7ABQQ4d3vyH6TFWTF pTHQBKnw1qdyhcMPIdJMSCslcWEUIp9lYHOzTk/T6Cz3C9kQsWLo0i/TFxJ3Y04xk7 7svTdcqsofQwNi8uDJn4wCT2qNN8ybK/e/uMxtA0= Authentication-Results: mxback13j.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by smtp2o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id cgajY6riR8-HpPSMOXQ; Sun, 17 Mar 2019 05:17:51 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) X-Mailer: geary/master~g91967edc X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:156427 gmane.emacs.devel:234249 Archived-At: I want to start by answering first likely question: the Community=20 Edition of gitlab should be fine license-wise, quoting Richard Stallman=20 "We have a simple way of looking at these two versions. The free=20 version is free software, so it is ethical."=C2=B9 Terms: "merge request" in gitlab means "patch series sent for review". ---- It makes me sad, seeing Emacs addons popping up, for a functional that=20 better could've been implemented in core. It's a lot of contributors=20 out there; at the same time, I see very little patches on emacs-devel=20 list. A lot of open-source projects already migrated to gitlab: all=20 FreeDesktop projects, all Gnome projects; and KDE are likely to migrate=20 soon too=C2=B2. Gnome reports: "After switching to GitLab, I noticed almost= =20 immediately an increase in contributions from people I hadn=E2=80=99t met=20 before. I think GitLab really lowered the threshold for people getting=20 started"=C2=B3. So, at the very least, migrating to gitlab should make contributions=20 easier for bigger part of the open-source world, peoples who used to=20 github and gitlab. (btw, here's a rarely mentioned point, why in=20 particular mailing-list workflow is hard for newcomers: almost every=20 mail client out there breaks formatting by default; and configuring=20 that out isn't always easy). Other points include: 1. I know some people like to operate with mails rather than=20 web-interface (which is what usual gitlab workflow based on). For them=20 gitlab can be configured to be managed with mails. I don't know how far=20 it stretches, but at the very least creating/replying to issues/merge=20 requests can be enabled.=E2=81=B4 2. Gitlab makes addressing review comments easier. With mailing lists=20 workflow you either need to =CE=B1) send a v2 of the patch; which is a=20 little frustrating: you need to find message-id to feed it to=20 git-send-email, and then you need to make sure its title lines up with=20 the rest of the series. Or =CE=B2) resend whole patch-series; which can be=20 just redundant when all you did was a one-line change, and clutters the=20 mailing list. Also, upon sending v3, v4, etc. you need to save=20 somewhere changes since v1. You can put it in actual commits, but for=20 git-history this information is unnecessary. With gitlab workflow, on=20 the other hand, you just force-push changes to the branch that has=20 merge-request opened. A single command, that it. 3. CI. I've recently seen someone on emacs-devel=E2=81=B5 asking a=20 contributor to run their syntax-checking script on a regular basis.=20 That's becase you can't run any check on a code hanging out there on a=20 mailing list in pure air. Gitlab supports CI, i.e. one can set it up to=20 run unit-tests for every merge-request created, so these errors get=20 caught before getting to the tree; and possibly even before getting to=20 eyes of reveiwers. 4. Impossible to lose "merge request". I've seen in Emacs docs an=20 advice to send patch series to a bugtracker, because on emacs-devel=20 they can easily be forgotten. That can't happen so easily with gitlab,=20 where you have a tab with open merge requests. 5. Discussion on patch series is easier to read. On mailing lists can=20 quickly appear a dozen of no longer relevant review mails, that refer=20 to something that was addressed. In Gitlab the addressed comments can=20 be marked as such, and get collapsed. 6. More tightly integrated bugtracker. When a commit refers to an=20 issue, it can be seen from inside the issue. This is useful e.g. when=20 someone fixed a problem, but for some reason couldn't address review=20 comments, leaving the code behind. Then later peoples who stumble upon=20 the same issue can just improve the code instead of doing research and=20 writing it on their own. 7. Unclear how to download a patch-series from mailing list. Usually=20 mailing-list driven projects add some system that tracks patches, and=20 allows to download series. E.g. that's how Mesa worked. But Emacs don't=20 seem to have one. With gitlab though you can simply fetch someone's=20 branch. 1:=20 https://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00095.htm= l 2:=20 http://kde.6490.n7.nabble.com/Gitlab-Evaluation-amp-Migration-td1708416.htm= l 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 =