From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Sat, 11 May 2019 02:12:06 +0000 Message-ID: <20190511021206.GA4049@ACM> References: <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> <83imuifqjc.fsf@gnu.org> <87lfzehrug.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="138395"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Eli Zaretskii , emacs-devel@gnu.org, toon@iotcl.com, 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 04:12:56 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 1hPHVP-000Ztm-Kk for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 04:12:55 +0200 Original-Received: from localhost ([127.0.0.1]:52666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPHVO-0005w2-Ch for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 22:12:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56065) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPHUh-0005vt-L4 for emacs-devel@gnu.org; Fri, 10 May 2019 22:12:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPHUg-0004LQ-JW for emacs-devel@gnu.org; Fri, 10 May 2019 22:12:11 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:46567 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hPHUg-0004HM-AK for emacs-devel@gnu.org; Fri, 10 May 2019 22:12:10 -0400 Original-Received: (qmail 36155 invoked by uid 3782); 11 May 2019 02:12:08 -0000 Original-Received: from acm.muc.de (p2E5D55A8.dip0.t-ipconnect.de [46.93.85.168]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 11 May 2019 04:12:06 +0200 Original-Received: (qmail 4063 invoked by uid 1000); 11 May 2019 02:12:06 -0000 Content-Disposition: inline In-Reply-To: <87lfzehrug.fsf@gmail.com> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:236400 Archived-At: Hello, Alex. On Fri, May 10, 2019 at 16:23:03 -0600, Alex Gramiak wrote: > Eli Zaretskii writes: > > 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. I don't know what "pull/merge request" means. Does it mean a request by an outsider for a core contributor to perform a "git pull" operation from the outsider's computer, the outsider having opened up his machine to public access to allow this? > Gitlab et al. would provide that, IMO. When there's no PR/MR at the > beginning, the topic is submitted as an "Issue" and given a unique issue > number. However, patches aren't submitted to the issue: rather, a new > PR/MR is created, given a unique MR number, and is linked with the > relevant issue(s). Yuck! I recently worked with a proprietory system where each bug had several different numbers, an issue number, an analysis number, a patch number, and so on. It caused extra effort to keep track of bugs, and was generally horrible. > When the PR/MR is merged, any linked issues are closed. You needn't have used the passive voice, there. What does your sentence mean? That when a user merges a PR/MR, gitlab automatically closes the issue (whether it's finished, or not)? Or that a user can close an issue only after somebody has first merged at least one PR/MR? Or something else? What is the point of issues and PR/MRs having distinct identifiers, if they are so tightly coupled with eachother? > This means that the discussion gets separated into two parts: the > discussion about the issue/problem (kept in the "Issues" category), and > the discussion about the patch/solution (kept in the "Merge Requests" > category). This sounds like a Bad Thing to me. It sounds rather like a workflow being imposed which imagines that first the bug gets "resolved" (whatever that means) in discussion, and only then does work start on a separate "merge request". The above mentioned proprietory system was like this. It didn't lend itself to a natural and efficient way of working. -- Alan Mackenzie (Nuremberg, Germany).