From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Sat, 11 May 2019 20:22:56 +0100 Message-ID: <8736lkyewf.fsf@tcd.ie> 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="261835"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru, Eli Zaretskii , toon@iotcl.com, Alex Gramiak To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 11 21:23:18 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 1hPXaW-0015rq-LJ for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 21:23:16 +0200 Original-Received: from localhost ([127.0.0.1]:34456 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPXaQ-0005I8-Dl for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 15:23:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPXaK-0005Hy-3n for emacs-devel@gnu.org; Sat, 11 May 2019 15:23:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPXaI-0003gT-4M for emacs-devel@gnu.org; Sat, 11 May 2019 15:23:03 -0400 Original-Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]:36056) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hPXaF-0003fe-Tf for emacs-devel@gnu.org; Sat, 11 May 2019 15:23:00 -0400 Original-Received: by mail-ed1-x541.google.com with SMTP id a8so10535003edx.3 for ; Sat, 11 May 2019 12:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=/B8+11QZngrBijmHmzi7cdStuM40l6/SJQDAsLiNUIs=; b=l6mDb3cDdkErYpzHGGP4hcfNiwWlqtcicyjnpNARRXRfgCccZhShWdai2/AVFJVv9R QcfWZvYb7yd0zno1KlqqcnwrI8C8dLjy9E6CcWfVY0HxIX/wmBIKIHYZzWKioPsMieI1 dwrq8uqC/i9TPwpVVgIUQzRD8q+DCVeAFCLUYf6NXUVyyTG886gOxNe1vqCPb0Gz4++n fKwB3aIjPDumw9d3fi4zbrBsoDnLznRFoy4uXHuwJnu8lmZbdHoE9iZvhxepfI9J/OK/ G7gI3Ic54WjnG+p9bNcFroZkxNNR8KLrkrh8hP3BqzE76yPYSTL8AYbX4Hl+ULk5Ok1n xy7Q== 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=/B8+11QZngrBijmHmzi7cdStuM40l6/SJQDAsLiNUIs=; b=OF5YgL7SrpHZGUAZ1aOmfhQ1f7evi6EQ2ea3AZeeFbG73RllES/I8AN0LjH6pWj3gV /50WfHFNRJ9kQnRFYv9M1aNshgzvUhwTOxU2RY7ea5eIpurwIVZAMJiIRvnlgLCBMp50 gB565+UNAU9TdVKFIXq/43Z+Ki1zBpYRvGCtkWZz7gxFL35VipW5J62sR/J1Grqyw6UP ygKz6ht2FW89bgvlpYH5qZ9s/Zq3gSoyB1Y8N50DXqFUngE6dzVsdXNdx6b2eyWrskvf yXlHi36b6RpkWC6x+KviueoM8aQjIoagSRJmIBDp+hTakrwum2I/5kGfkeEXNF9jEEqP 65iA== X-Gm-Message-State: APjAAAVHQSDc9zq88qzvqg3ikQ8JAzVySengnNKKbxDuKfNZQ/hE9TzA mzPd+NDI0a44nLLsWz0UtIGWNw== X-Google-Smtp-Source: APXvYqwMzNWxGW3LTg6I7sk6q7WNN8Hk7ggjq1s5VzvnUL6aAyux4/XwAJyvheYjvqsvgPPq7YbfGw== X-Received: by 2002:a17:906:958:: with SMTP id j24mr6095526ejd.160.1557602578582; Sat, 11 May 2019 12:22:58 -0700 (PDT) Original-Received: from localhost ([2a02:8084:20e2:c380:8cad:ae29:555d:852d]) by smtp.gmail.com with ESMTPSA id c48sm2514240edc.76.2019.05.11.12.22.57 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sat, 11 May 2019 12:22:57 -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: 2a00:1450:4864:20::541 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:236439 Archived-At: Alan Mackenzie writes: > 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? A {pull,merge} request is a diff of two Git branches for which the issue tracker cum Git forge (GitLab) creates a dedicated ticket with which ensuing discussion and other metadata is associated. In simplistic terms, it's like an interactive set of patches. The two branches in question are: (1) the branch containing the submitter's proposed changes, and (2) the upstream branch these changes are intended to be merged into. The two branches can live either in the same repository, or in separate "forks" (copies) of the same repository. The former case means that the submitter already has push access to the centralised upstream repository. The latter case is more common for first-time and infrequent contributors who do not have push access, and thus have no option but to create their merge requests (patch sets) against their personal fork/copy/checkout of the upstream repository. >> 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. Each bug report ("issue") has only a single number. Similarly each merge request has only a single number. Merge requests are often submitted to address an existing issue, in which case the relevant Git commit messages and/or merge request description canonically contain a textual reference to this issue. But it is up to the submitter and/or reviewers to ensure such a reference is mentioned somewhere; the UI does not force it upon anyone. >> 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? They are not that tightly coupled to each other. Issues and merge requests can be opened and closed independently of one another and in any order, and each issue needn't be associated with a merge request, and vice versa. Even if they are associated, this association is mostly implicit in the text of the discussion, not something imposed by GitLab. As mentioned elsewhere in this thread, however, GitLab can automatically take certain known actions based on specially crafted command phrases included as part of commit messages or discussion comments, for convenience. For example, if a merge request contains a commit which includes the phrase "Fixes #123", then merging the merge request (i.e. merging its constituent commits into the upstream branch) causes GitLab to automatically close bug number 123. Similarly including an automatically stripped command such as "/close" in a comment causes its issue or merge request to be 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 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. The workflow is mostly up to the maintainers to design. Issues and merge requests are independent entities - one mustn't come before the other. The only difference is that issues are discussion-only (though code snippets and diffs can of course be included as part of a comment, and can even be prettified with syntax highlighting in the web UI), whereas merge-requests additionally contain a realtime comparison of the current state of two Git branches, and allow interactive commenting on specific lines of the diff. How issues and merge requests are used, linked, labelled, etc. is up to the maintainers. Thanks, -- Basil