From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel,gmane.emacs.bugs Subject: Re: [RFE] Migration to gitlab Date: Sun, 17 Mar 2019 09:48:23 -0700 Message-ID: <87r2b578h4.fsf@ericabrahamsen.net> References: <1552789070.5272.1@yandex.ru> <1552791707.5272.2@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="111923"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: bug-gnu-emacs@gnu.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 17 18:01:14 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 1h5Z9s-000Swx-Kl for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2019 18:01:12 +0100 Original-Received: from localhost ([127.0.0.1]:57866 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5Z9r-0005lI-Ji for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2019 13:01:11 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5Z8U-0005TN-ID for emacs-devel@gnu.org; Sun, 17 Mar 2019 12:59:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h5Yxo-0002LO-Fr for emacs-devel@gnu.org; Sun, 17 Mar 2019 12:48:45 -0400 Original-Received: from [195.159.176.226] (port=51252 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h5Yxo-0002KT-6z for emacs-devel@gnu.org; Sun, 17 Mar 2019 12:48:44 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1h5Yxg-000Fm1-12 for emacs-devel@gnu.org; Sun, 17 Mar 2019 17:48:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Followup-To: gmane.emacs.devel Cancel-Lock: sha1:vDfGh4hVvXbO4Fsb3psBfe6/05I= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:234277 gmane.emacs.bugs:156439 Archived-At: Konstantin Kharlamov writes: > В Вс, мар 17, 2019 at 5:17 ДП (AM), 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 > > 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/