From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Sat, 11 May 2019 09:22:19 +0300 Message-ID: <83pnopecis.fsf@gnu.org> References: <1552789070.5272.1@yandex.ru> <87imwhmmt8.fsf@gmail.com> <87y347g1l3.fsf@iotcl.com> <9ac21e82-8e47-f9b5-f88d-23c0c56946d1@yandex.ru> <87pnpc1lby.fsf@iotcl.com> <83zhoezdqc.fsf@gnu.org> <87imuivfcr.fsf@iotcl.com> <83k1eyfxls.fsf@gnu.org> <3b8e2195-07c0-a240-6164-8d34bcca344f@yandex.ru> <83ftpmfp0y.fsf@gnu.org> <838svefl3p.fsf@gnu.org> <658fcd11-dfad-2060-c84b-5da938d506b7@yandex.ru> <83woiydorm.fsf@gnu.org> <87pnoqht2u.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="103933"; mail-complaints-to="usenet@blaine.gmane.org" Cc: toon@iotcl.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Alex Gramiak Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 11 08:23:03 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 1hPLPT-000Qu3-5N for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 08:23:03 +0200 Original-Received: from localhost ([127.0.0.1]:54960 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPLPS-00067E-1G for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 02:23:02 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPLOr-000679-Jy for emacs-devel@gnu.org; Sat, 11 May 2019 02:22:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPLOq-000340-P8; Sat, 11 May 2019 02:22:24 -0400 Original-Received: from [176.228.60.248] (port=4392 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hPLOq-00076V-AU; Sat, 11 May 2019 02:22:24 -0400 In-reply-to: <87pnoqht2u.fsf@gmail.com> (message from Alex Gramiak on Fri, 10 May 2019 15:56:25 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:236406 Archived-At: > From: Alex Gramiak > Cc: Dmitry Gutov , toon@iotcl.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Fri, 10 May 2019 15:56:25 -0600 > > Eli Zaretskii writes: > > > I wonder if I'm the only one here who feels that way. I mean, one of > > the more important advantages of Emacs is that it lets you do many > > things only tangentially related to editing program sources, and now > > we suddenly are willing to give that up? Really?? > > I imagine that most of the people advocating for a switch to platforms > like Gitlab don't want to give that up; instead, the browser would just > be an alternative for people who don't (perhaps yet) want to (or know > how to) do it in Emacs all the time. I believe you are talking about a system with dual interface: one via a browser, and another that allows to use Emacs for most of the tasks. That'd be OK at least with me, but the problem is I don't yet see how this could be done with GitLab or any other system that was mentioned in the discussions so far. > A problem here seems to be that Gitlab, outside of its browser workflow, > doesn't currently offer some niceties that are to be expected, but > hopefully this discussion helps to nudge the right people to work on > these features there. I really hope so. > If switching to Gitlab was given the OK by you and other core > contributors after the desired features are available in Gitlab For this, we'd need to agree on the list of the desired features, probably prioritized by their importance. Once we have that, we could decide that having all the features whose priority is greater than some agreed-upon number N is enough to switch. Theoretically, I don't see any problems with this decision; the devil is as always in the details: to come up with a list of the features, agree on their priorities, and implement them. Thanks.