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 Subject: Re: [RFE] Migration to gitlab Date: Sun, 17 Mar 2019 17:06:40 +0300 Message-ID: <1552831600.21432.2@yandex.ru> References: <1552789070.5272.1@yandex.ru> <1552829033.21432.1@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="243830"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Philippe Vaucher , emacs-devel To: Tadeus Prastowo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 17 15:14:51 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 1h5WYt-0011Ls-2M for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2019 15:14:51 +0100 Original-Received: from localhost ([127.0.0.1]:56160 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5WYs-00029d-0B for ged-emacs-devel@m.gmane.org; Sun, 17 Mar 2019 10:14:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5WXZ-0001pk-Hq for emacs-devel@gnu.org; Sun, 17 Mar 2019 10:13:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h5WR4-0005R0-79 for emacs-devel@gnu.org; Sun, 17 Mar 2019 10:06:46 -0400 Original-Received: from forward100o.mail.yandex.net ([37.140.190.180]:48727) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h5WR3-0005PA-97 for emacs-devel@gnu.org; Sun, 17 Mar 2019 10:06:46 -0400 Original-Received: from mxback18o.mail.yandex.net (mxback18o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::69]) by forward100o.mail.yandex.net (Yandex) with ESMTP id A6F034AC1796; Sun, 17 Mar 2019 17:06:42 +0300 (MSK) Original-Received: from smtp4j.mail.yandex.net (smtp4j.mail.yandex.net [2a02:6b8:0:1619::15:6]) by mxback18o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id R7PTzpkvgp-6g8qtVHJ; Sun, 17 Mar 2019 17:06:42 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1552831602; bh=ZRS0PFj/ijgLdj8Iszf+LB3rxDuX/b//Blu4tjFQqB4=; h=In-Reply-To:Cc:To:Subject:From:References:Date:Message-Id; b=JWS7r/mUw2z+q4iHHbYAasmpy3We2pzmZ5GL3Xu19LHZTBlRLM2z8Pv5R0XBOBDUv CD24qubB9rG6JVNDZHpxD2TE9Me3Ns3j6zX95sV3HPn7BFnXwVPhcxMI3IfZabfCL/ +xozcXi9G/FA7b6brnrBMBHYxavjf+Nq3V0i+R98= Authentication-Results: mxback18o.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by smtp4j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id FohdE3jWtj-6fGCXDun; Sun, 17 Mar 2019 17:06:41 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) In-Reply-To: X-Mailer: geary/master~g91967edc X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 37.140.190.180 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:234268 Archived-At: =C2 =C2=F1, =EC=E0=F0 17, 2019 at 4:49 =CF=CF (PM), Tadeus Prastowo=20 =ED=E0=EF=E8=F1=E0=EB: > On Sun, Mar 17, 2019 at 2:23 PM Konstantin Kharlamov=20 > wrote: >>=20 >>=20 >>=20 >> =C2 =C2=F1, =EC=E0=F0 17, 2019 at 4:14 =CF=CF (PM), Tadeus Prastowo >> =ED=E0=EF=E8=F1=E0=EB: >> > IMO, I feel more comfortable with the current Emacs model because=20 >> I >> > see less noise in the interface. Furthermore, the current model >> > allows me to do my own way of automation against a stable simple >> > interface (plain-text e-mails and textual command lines have been >> > around for a long time). This may not be welcoming to newcomers,=20 >> but >> > I once was a newcomer in the Linux kernel dev but found nothing so >> > difficult about it. >>=20 >> The automation sounds a bit abstract, >=20 > The automation of copying and pasting message-id and the like. >=20 >> but I guess you still can do it >> if gitlab have enabled replying/opening of merge requests through=20 >> mails. >=20 > As you wrote in the initial e-mail, e-mails are not the primary means > of gitlab model, and so, how far it can be stretched and how long it > will keep being supported remain to be seen. Seeing the stretching is > rather easy because it can be done now. But, it is impossible to see > how long it will keep being supported in the gitlab model. Sure this part is just a contemplation, but I think that usage of=20 emails was added to gitlab in the first place to keep workflow of=20 peoples who got used to mailing lists. In that case I'd expect this to=20 be enhanced rather than removed in the future (of course in the end=20 this depends on demand or contributions from other peoples. And you are=20 a creator of that demand). >> Also, Linux kernel and git has "patchwork" site that essentially=20 >> tracks >> open patch-series, versions of patches, comments to them, allows to >> download latest series=85 It is more advanced than just the mailing >> list as GNU Emacs has. >=20 > Yes, as you pointed out in the initial e-mail, a mailing list itself > is not enough. That causes the chore of copying and pasting and the > like, which can be automated, especially if Emacs is used. The > perspective that I support is that of heterogeneity. IMO, the gitlab > model is into homogeneity: one uniform system for everything, but that > sacrifices flexibility. I just don't see how could gitlab workflow interfere with that. If=20 anything, it helps automating the chore of copying and pasting, because=20 now you can get someone's series by a simple `git fetch remote branch`. =