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:32:00 +0300 Message-ID: <83k1exec2n.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> <83imuifqjc.fsf@gnu.org> <87lfzehrug.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="185131"; mail-complaints-to="usenet@blaine.gmane.org" Cc: toon@iotcl.com, dgutov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alex Gramiak Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 11 08:41:58 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 1hPLhl-000m2a-Cc for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 08:41:57 +0200 Original-Received: from localhost ([127.0.0.1]:55123 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPLhk-00039w-1y for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 02:41:56 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPLhQ-0002Xi-6b for emacs-devel@gnu.org; Sat, 11 May 2019 02:41:37 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35703) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPLYE-0001cP-Bw; Sat, 11 May 2019 02:32:06 -0400 Original-Received: from [176.228.60.248] (port=4985 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hPLYD-0007Zh-OS; Sat, 11 May 2019 02:32:06 -0400 In-reply-to: <87lfzehrug.fsf@gmail.com> (message from Alex Gramiak on Fri, 10 May 2019 16:23:03 -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:236408 Archived-At: > From: Alex Gramiak > Cc: toon@iotcl.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru > Date: Fri, 10 May 2019 16:23:03 -0600 > > > So we must have a good support for a workflow that doesn't include any > > pull/merge request at its beginning, maybe even never. > > 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. What interests me is which features make discussing an issue easier than with debbugs. What you describe above is in general identical to how we do that on debbugs (except that there's no Web UI). > 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). When the PR/MR is merged, any linked issues are > closed. > > 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 separation is IME not a good thing. Integrated issue trackers should have them both together. I should be able to create a PR/MR directly from the issue, or vice versa, instead of creating a new object and then linking it to an old one. But maybe in practice this separation is not important enough to care about.