From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alex Gramiak Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Sat, 11 May 2019 18:58:27 -0600 Message-ID: <871s14ij4c.fsf@gmail.com> 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> <20190511021206.GA4049@ACM> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="74162"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org, toon@iotcl.com, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 12 02:59:11 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 1hPcpa-000J9U-LH for ged-emacs-devel@m.gmane.org; Sun, 12 May 2019 02:59:11 +0200 Original-Received: from localhost ([127.0.0.1]:37095 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPcpZ-00034c-3P for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 20:59:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPcow-00034L-PJ for emacs-devel@gnu.org; Sat, 11 May 2019 20:58:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPcou-0006eA-Ro for emacs-devel@gnu.org; Sat, 11 May 2019 20:58:30 -0400 Original-Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]:40772) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hPcos-0006dZ-VB; Sat, 11 May 2019 20:58:27 -0400 Original-Received: by mail-pf1-x434.google.com with SMTP id u17so5192572pfn.7; Sat, 11 May 2019 17:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=dX1dVSB4qHxEa5TPOl9HXmspuNYPlbHzstNOXEljLjE=; b=X1vPDqf5kZIgAuELotPrAlOU7bqaE6LJTPTjdcQ9nuy3ivahzqwzU85KJuc9dWdY12 DfwRpVhwS/HZMkcQqI1LT5Ffp6RAORK0feWL34PO6WOjgY4+D571chRSIj1iioVMsch2 zZEC5zOobbo74H0PcWVcJL7lOQnowpuZCqfsGvetqJndgVDJxHpJSycswdMvdfRKgkap T5cRWsjNoqke788aCLp7d4J52p+Xcuoue+Mmf6uHdINcMDjSPav/dwRVcK+Y4qu76hNs uU6p/A10sLzwemCwtQ1VZ1zhooc+U6Xmnp6srdvcJpfO8B/oLtkrV6BaYzhiOn9VCPeB SEWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=dX1dVSB4qHxEa5TPOl9HXmspuNYPlbHzstNOXEljLjE=; b=nVEcV6TV7Hbt14Q5cDD3kVjl5R8jO7043TCZIxuO2Vd0dEvTf5R+rcDAS0ZKRxShfO J2Wqj/nDVDYGgnO13sy0D1N6BYo5NMKHgjUX4xQTi5X38MahkhVo2Of5mbwLjNan45tk Mp5FfaqkEeb+qqaFX4rtK2iwHV48i1/9aJ6HXZa8K45HpbCU2DSc6mXg1LQQROEU8e7Z +thDZT6T7iU9o1METbC5NaAB2c/fpZOubMSIdj7GqN+EW49Ex15WAdxWk+WCdulrSQ49 R3QpyxXdJNyKRmOyRPP17Lk1ZY5dMd14B4dtmdXXPBTjKCfqehiulkGox9KAi3qShgoq JYXg== X-Gm-Message-State: APjAAAUv79HSTxEcVVubdtjTeR19DGxIZBrZcwES3sb1gqdETkIojkBI 8Gv4eksf9t8aO0LLGK2NCXnjSahs X-Google-Smtp-Source: APXvYqxznolwvHD6RysXZc+qJEMlvHR1wyhAhzP6BEqrDlqIJcoXxA9YNDqE3SCR2/pX9uLjubAQKg== X-Received: by 2002:a63:5202:: with SMTP id g2mr23704500pgb.317.1557622704881; Sat, 11 May 2019 17:58:24 -0700 (PDT) Original-Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id 79sm3515455pfz.144.2019.05.11.17.58.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 11 May 2019 17:58:24 -0700 (PDT) In-Reply-To: <20190511021206.GA4049@ACM> (Alan Mackenzie's message of "Sat, 11 May 2019 02:12:06 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::434 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:236444 Archived-At: Hi, Alan. Alan Mackenzie writes: > 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? Typically a local copy of the repository is uploaded somewhere else so that the server can access the branch. Outsiders should be able to make an account on a hypothetical GNU Gitlab instance, push their repository to their account, and then have the MR be between that repository and the upstream in the GNU Gitlab instance. For example, [1] (under Using a fork - Non GNOME developer) describes how this process works for outsiders for the GNOME project. Basil gave a good description of pull/merge requests, but here[2] is an example picture of a merge request in the Gitlab web UI. The main body consists of a topic and MR comment, which includes several sections in Markdown and a special phrase "Closes #46869" that will automatically close issue #46869 when the MR is accepted. The phrase can also occur in a commit message instead of the MR message. The right sidebar includes some metadata like the assignee, milestone, labels, and participant list. Below the comment is the status of the MR. Below that is the discussion, list of commits, the pipelines[3], and the diff of the MR. >> 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. That indeed sounds awful, but IMO the Gitlab style is different as there are only two categories, with the bug (an issue) having a single ID, and a set of MRs containing separate IDs. Keeping track of bugs would usually just involve using the issue number, not the MR number. >> 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)? Only if the submitter (or merger if the server allows) specifies that the MR closes the issue. See [4] for how Gitlab handles this. >> 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. To reiterate what Basil said, it's up to the maintainers in how MRs would be used (though too significant of a departure from the standard would detract from the newcomer-friendly aspect of this move). All discussion could be in the issue with no comments in the MR outside of comments specifically about the implementation of the MR. I can see how the workflow could include some aspects that might be somewhat unnatural/inefficient (such as a discussion about the bug in the MR that has to be summarized/duplicated/linked in the issue), but I don't think that it's much of a deal in this type of system. As with any system, a certain class of workflows is imposed, but this system, while encouraging a thorough discussion on the issue side first, can still have MR(s) being worked on while the discussion in the issue is ongoing. It's just that the discussion for the MR is separated from the issue at large. One can think of the MR discussion as a separate email subthread for the main/issue thread. [1] https://wiki.gnome.org/GitLab [2] https://docs.gitlab.com/ee/user/project/merge_requests/img/merge_request.png [3] https://docs.gitlab.com/ee/ci/pipelines.html [4] https://docs.gitlab.com/ce/user/project/issues/automatic_issue_closing.html