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.devel,gmane.emacs.bugs Subject: Re: [RFE] Migration to gitlab Date: Sun, 17 Mar 2019 06:01:47 +0300 Message-ID: <1552791707.5272.2@yandex.ru> References: <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="128518"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel To: bug-gnu-emacs@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 17 04:20:07 2019 Return-path: Envelope-to: ged-emacs-devel@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 1h5MLG-000XHw-5n for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2019 04:20:06 +0100 Original-Received: from localhost ([127.0.0.1]:49498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5MLE-0002xK-Eh for ged-emacs-devel@m.gmane.org; Sat, 16 Mar 2019 23:20:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5MKS-0002jV-LM for emacs-devel@gnu.org; Sat, 16 Mar 2019 23:19:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h5MEp-0000de-Sj for emacs-devel@gnu.org; Sat, 16 Mar 2019 23:13:29 -0400 Original-Received: from forward103j.mail.yandex.net ([2a02:6b8:0:801:2::106]:47036) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h5MEn-0000Yt-PT; Sat, 16 Mar 2019 23:13:26 -0400 Original-Received: from mxback19g.mail.yandex.net (mxback19g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:319]) by forward103j.mail.yandex.net (Yandex) with ESMTP id 33D5467415D0; Sun, 17 Mar 2019 06:01:49 +0300 (MSK) Original-Received: from smtp4o.mail.yandex.net (smtp4o.mail.yandex.net [2a02:6b8:0:1a2d::28]) by mxback19g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id bg4a14Amea-1nCCxth0; Sun, 17 Mar 2019 06:01:49 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1552791709; bh=lmyQsGhmRIHQyK+HP/dWuCJu/E6AlhIldR+h8rDulp8=; h=In-Reply-To:Cc:To:Subject:From:References:Date:Message-Id; b=EDhnYo4nlAN2dmyNbjuBK8C5Dr9P+xb5/Fk6EB0vFydFW+BBiyHmzm8aPtHZCDGCj 0livzmKG0HO9loINVUGPoJc15obss4gYavibaiIni+nJiMiKFaZQz0CCu5b121XesM ER+7nssV46wYjHmNGFaMJ8S6jMJRXG0zLJrLhctk= Authentication-Results: mxback19g.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by smtp4o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 2q66plbm34-1ljuOngF; Sun, 17 Mar 2019 06:01:48 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) In-Reply-To: <1552789070.5272.1@yandex.ru> X-Mailer: geary/master~g91967edc X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a02:6b8:0:801:2::106 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:234252 gmane.emacs.bugs:156428 Archived-At: =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 > Edition of gitlab should be fine license-wise, quoting Richard=20 > Stallman "We have a simple way of looking at these two versions. The=20 > free version is free software, so it is ethical."=C2=B9 >=20 > Terms: "merge request" in gitlab means "patch series sent for review". >=20 > ---- >=20 > It makes me sad, seeing Emacs addons popping up, for a functional=20 > that better could've been implemented in core. It's a lot of=20 > contributors out there; at the same time, I see very little patches=20 > on emacs-devel list. >=20 > A lot of open-source projects already migrated to gitlab: all=20 > FreeDesktop projects, all Gnome projects; and KDE are likely to=20 > migrate soon too=C2=B2. Gnome reports: "After switching to GitLab, I=20 > noticed almost immediately an increase in contributions from people I=20 > hadn=E2=80=99t met before. I think GitLab really lowered the threshold fo= r=20 > people getting started"=C2=B3. >=20 > 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). >=20 > 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=20 > them gitlab can be configured to be managed with mails. I don't know=20 > how far it stretches, but at the very least creating/replying to=20 > issues/merge requests can be enabled.=E2=81=B4 > 2. Gitlab makes addressing review comments easier. With mailing=20 > lists workflow you either need to =CE=B1) send a v2 of the patch; which=20 > is a 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=20 > with the rest of the series. Or =CE=B2) resend whole patch-series; which=20 > can be just redundant when all you did was a one-line change, and=20 > clutters the mailing list. Also, upon sending v3, v4, etc. you need=20 > to save somewhere changes since v1. You can put it in actual commits,=20 > but for git-history this information is unnecessary. With gitlab=20 > workflow, on the other hand, you just force-push changes to the=20 > branch 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 > 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=20 > a mailing list in pure air. Gitlab supports CI, i.e. one can set it=20 > up to run unit-tests for every merge-request created, so these errors=20 > get caught before getting to the tree; and possibly even before=20 > getting to 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=20 > gitlab, where you have a tab with open merge requests. > 5. Discussion on patch series is easier to read. On mailing lists=20 > can quickly appear a dozen of no longer relevant review mails, that=20 > refer to something that was addressed. In Gitlab the addressed=20 > comments can 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=20 > upon the same issue can just improve the code instead of doing=20 > research and 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=20 > don't seem to have one. With gitlab though you can simply fetch=20 > someone's branch. >=20 > 1:=20 > https://lists.gnu.org/archive/html/libreplanet-discuss/2015-03/msg00095.h= tml > 2:=20 > http://kde.6490.n7.nabble.com/Gitlab-Evaluation-amp-Migration-td1708416.h= tml > 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=20 mailing list subscribers see, and what web-interface renders. E.g. the=20 nicely formatted list of points above from the outside worls looks like=20 a large single line:=20 http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00531.html =