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 06:34:06 +0300 Message-ID: <1552793646.5272.3@yandex.ru> References: <1552789070.5272.1@yandex.ru> <1552791707.5272.2@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="260136"; 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 04:55:08 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 1h5MtA-0015aV-4U for geb-bug-gnu-emacs@m.gmane.org; Sun, 17 Mar 2019 04:55:08 +0100 Original-Received: from localhost ([127.0.0.1]:49775 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5Mt8-00018D-V2 for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Mar 2019 23:55:06 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5Mqp-0007ZW-1C for bug-gnu-emacs@gnu.org; Sat, 16 Mar 2019 23:52:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h5MZi-0000kI-FC for bug-gnu-emacs@gnu.org; Sat, 16 Mar 2019 23:35:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33284) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h5MZi-0000iw-80 for bug-gnu-emacs@gnu.org; Sat, 16 Mar 2019 23:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h5MZh-0002Lk-Pd for bug-gnu-emacs@gnu.org; Sat, 16 Mar 2019 23:35:01 -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 03:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34889 X-GNU-PR-Package: emacs Original-Received: via spool by 34889-submit@debbugs.gnu.org id=B34889.15527936618978 (code B ref 34889); Sun, 17 Mar 2019 03:35:01 +0000 Original-Received: (at 34889) by debbugs.gnu.org; 17 Mar 2019 03:34:21 +0000 Original-Received: from localhost ([127.0.0.1]:46828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5MYz-0002Kh-Px for submit@debbugs.gnu.org; Sat, 16 Mar 2019 23:34:21 -0400 Original-Received: from forward104j.mail.yandex.net ([5.45.198.247]:46001) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h5MYx-0002KR-IU for 34889@debbugs.gnu.org; Sat, 16 Mar 2019 23:34:16 -0400 Original-Received: from mxback8j.mail.yandex.net (mxback8j.mail.yandex.net [IPv6:2a02:6b8:0:1619::111]) by forward104j.mail.yandex.net (Yandex) with ESMTP id F3B8B4A074B; Sun, 17 Mar 2019 06:34:08 +0300 (MSK) Original-Received: from smtp1j.mail.yandex.net (smtp1j.mail.yandex.net [2a02:6b8:0:801::ab]) by mxback8j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id teVxO3a4Jt-Y8AqlBGG; Sun, 17 Mar 2019 06:34:08 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1552793648; bh=MmUeBJO9dAuYVyl9euk5CDWoPITHGYzpp6ru6geZdnk=; h=In-Reply-To:Cc:To:Subject:From:References:Date:Message-Id; b=rNB5Q+9RVj+dKzw6kR9wa1NNRnQguL+msenra+EiPCLYefuQwkqI2N7G/ne1b+fi7 L75S9x2T2qffw0ApVI35Ppf/LICRfXxN8CukdBx+0q8Z0TIAp+NpwJHTEKcOWF5uMT RDS8GWz3RBQB8Fbde37b3Z3o/mto5P+FopIn2rtE= Authentication-Results: mxback8j.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by smtp1j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id atD8BIRPGS-Y7misnga; Sun, 17 Mar 2019 06:34:07 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) In-Reply-To: <1552791707.5272.2@yandex.ru> X-Mailer: geary/master~g91967edc 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:156430 gmane.emacs.devel:234257 Archived-At: Oops. Please, reply to this mail, I haven't thought that mails to=20 bugs-gnu gonna create new reports. Fixed here. =D0=92 =D0=92=D1=81, =D0=BC=D0=B0=D1=80 17, 2019 at 6:01 =D0=94=D0=9F (AM),= Konstantin Kharlamov=20 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >=20 >=20 > =D0=92 =D0=92=D1=81, =D0=BC=D0=B0=D1=80 17, 2019 at 5:17 =D0=94=D0=9F (AM= ), Konstantin Kharlamov=20 > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >> I want to start by answering first likely question: the Community=20 >> =7FEdition of gitlab should be fine license-wise, quoting Richard=20 >> =7FStallman "We have a simple way of looking at these two versions.=20 >> The =7Ffree version is free software, so it is ethical."=C2=B9 >>=20 >> Terms: "merge request" in gitlab means "patch series sent for=20 >> review". >>=20 >> ---- >>=20 >> It makes me sad, seeing Emacs addons popping up, for a functional=20 >> =7Fthat better could've been implemented in core. It's a lot of=20 >> =7Fcontributors out there; at the same time, I see very little patches=20 >> =7Fon emacs-devel list. >>=20 >> A lot of open-source projects already migrated to gitlab: all=20 >> =7FFreeDesktop projects, all Gnome projects; and KDE are likely to=20 >> =7Fmigrate soon too=C2=B2. Gnome reports: "After switching to GitLab, I=20 >> =7Fnoticed almost immediately an increase in contributions from people=20 >> I =7Fhadn=E2=80=99t met before. I think GitLab really lowered the thresh= old=20 >> for =7Fpeople getting started"=C2=B3. >>=20 >> So, at the very least, migrating to gitlab should make contributions=20 >> =7Feasier for bigger part of the open-source world, peoples who used=20 >> to =7Fgithub and gitlab. (btw, here's a rarely mentioned point, why in=20 >> =7Fparticular mailing-list workflow is hard for newcomers: almost=20 >> every =7Fmail client out there breaks formatting by default; and=20 >> configuring =7Fthat out isn't always easy). >>=20 >> Other points include: >> 1. I know some people like to operate with mails rather than=20 >> =7Fweb-interface (which is what usual gitlab workflow based on). For=20 >> =7Fthem gitlab can be configured to be managed with mails. I don't=20 >> know =7Fhow far it stretches, but at the very least creating/replying=20 >> to =7Fissues/merge requests can be enabled.=E2=81=B4 >> 2. Gitlab makes addressing review comments easier. With mailing=20 >> =7Flists workflow you either need to =CE=B1) send a v2 of the patch; whi= ch=20 >> =7Fis a little frustrating: you need to find message-id to feed it to=20 >> =7Fgit-send-email, and then you need to make sure its title lines up=20 >> =7Fwith the rest of the series. Or =CE=B2) resend whole patch-series;=20 >> which =7Fcan be just redundant when all you did was a one-line change,=20 >> and =7Fclutters the mailing list. Also, upon sending v3, v4, etc. you=20 >> need =7Fto save somewhere changes since v1. You can put it in actual=20 >> commits, =7Fbut for git-history this information is unnecessary. With=20 >> gitlab =7Fworkflow, on the other hand, you just force-push changes to=20 >> the =7Fbranch that has merge-request opened. A single command, that it. >> 3. CI. I've recently seen someone on emacs-devel=E2=81=B5 asking a=20 >> =7Fcontributor to run their syntax-checking script on a regular basis.=20 >> =7FThat's becase you can't run any check on a code hanging out there=20 >> on =7Fa mailing list in pure air. Gitlab supports CI, i.e. one can set=20 >> it =7Fup to run unit-tests for every merge-request created, so these=20 >> errors =7Fget caught before getting to the tree; and possibly even=20 >> before =7Fgetting to eyes of reveiwers. >> 4. Impossible to lose "merge request". I've seen in Emacs docs an=20 >> =7Fadvice to send patch series to a bugtracker, because on emacs-devel=20 >> =7Fthey can easily be forgotten. That can't happen so easily with=20 >> =7Fgitlab, where you have a tab with open merge requests. >> 5. Discussion on patch series is easier to read. On mailing lists=20 >> =7Fcan quickly appear a dozen of no longer relevant review mails, that=20 >> =7Frefer to something that was addressed. In Gitlab the addressed=20 >> =7Fcomments can be marked as such, and get collapsed. >> 6. More tightly integrated bugtracker. When a commit refers to an=20 >> =7Fissue, it can be seen from inside the issue. This is useful e.g.=20 >> when =7Fsomeone fixed a problem, but for some reason couldn't address=20 >> review =7Fcomments, leaving the code behind. Then later peoples who=20 >> stumble =7Fupon the same issue can just improve the code instead of=20 >> doing =7Fresearch and writing it on their own. >> 7. Unclear how to download a patch-series from mailing list.=20 >> Usually =7Fmailing-list driven projects add some system that tracks=20 >> patches, and =7Fallows to download series. E.g. that's how Mesa=20 >> worked. But Emacs =7Fdon't seem to have one. With gitlab though you=20 >> can simply fetch =7Fsomeone's branch. >>=20 >> 1:=20 >> =7Fhttps://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg000= 95.html >> 2:=20 >> =7Fhttp://kde.6490.n7.nabble.com/Gitlab-Evaluation-amp-Migration-td17084= 16.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:=20 >> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00131.html >=20 > Btw, one more point I just got: no more discrepancy between what=20 > mailing list subscribers see, and what web-interface renders. E.g.=20 > the nicely formatted list of points above from the outside worls=20 > looks like a large single line:=20 > http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00531.html >=20 >=20 >=20 =