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: Fri, 10 May 2019 15:21:59 +0300 Message-ID: <83imuifqjc.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> <17D21056-10B2-4813-AE90-9B2706936CE9@icloud.com> 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="48231"; mail-complaints-to="usenet@blaine.gmane.org" Cc: toon@iotcl.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, agrambot@gmail.com, dgutov@yandex.ru To: =?utf-8?B?7KGw7ISx67mI?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 10 14:22:26 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 1hP4Xi-000COi-9H for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 14:22:26 +0200 Original-Received: from localhost ([127.0.0.1]:42544 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP4Xh-0000jM-AC for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 08:22:25 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP4Xa-0000i8-KF for emacs-devel@gnu.org; Fri, 10 May 2019 08:22:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP4XY-0001zk-0c; Fri, 10 May 2019 08:22:16 -0400 Original-Received: from [176.228.60.248] (port=1625 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hP4XW-0004lj-9p; Fri, 10 May 2019 08:22:15 -0400 In-reply-to: <17D21056-10B2-4813-AE90-9B2706936CE9@icloud.com> (message from =?utf-8?B?7KGw7ISx67mI?= on Fri, 10 May 2019 19:37:31 +0900) 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:236364 Archived-At: > From: 조성빈 > Date: Fri, 10 May 2019 19:37:31 +0900 > Cc: Toon Claes , dgutov@yandex.ru, monnier@iro.umontreal.ca, > agrambot@gmail.com, emacs-devel@gnu.org > > > Note how you again start from a change, not from a report of some > > issue/bug. As Emacs is a very old and stable project, most of our > > changes fix bugs, not add new features. Therefore, use cases that > > begin with issues are much more important to the workflow and to > > assessing the utility of the tools. > > Any contributor can freely submit a pull request that has the word `Fixes #(Issue number)` and when the pull request is accepted, the issue is automatically closed. My point was that an absolute majority of Emacs issues don't have a patch attached. They describe a problem, and most of the reports don't even include a detailed analysis of the problem and its root cause. A large part of discussing an issue is devoted to understanding the issue and then finding its cause. Patches appear only after all that. So we must have a good support for a workflow that doesn't include any pull/merge request at its beginning, maybe even never. > >> Exaggerated in which sense? > > > > In the sense of representing various aspects of the current flow as > > abysmally inadequate, and the proposed solutions as no less than a > > panacea. > > Both workflows are inadequate Not really relevant to the question and the answer. > and overly complicated, but most people will be more familiar to the Gitlab Pull request workflow, and greatly lowers the bar for people who would like to contribute for the first time. Please don't forget that any change should also not unduly _raise_ the bar for the current core team, to be acceptable. > > Personally, I think an Emacs client is almost a must, if we want to > > consider something like GitLab seriously. > > There are many Emacs clients that tightly integrates with magit; I assume you use magit for managing git repos? > > The best one IMO is the official (magit) one: > Release: https://emacsair.me/2018/12/19/forge-0.1/ > Manula: https://magit.vc/manual/forge/ > Repo: https://github.com/magit/forge It sounds like you are advocating the adoption of a system other than GitLab. If so, I think we should first decide that GitLab is not good enough, something I believe we didn't decide yet. > It works with Github and Gitlab, and semi-supports Gitea and other forges. If by "it" you mean forge, would you please describe how it would be used in the Emacs maintenance workflows? (Having to install magit is a certain disadvantage, but it isn't by itself enough to make this alternative unacceptable, IMO.)