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: Sun, 12 May 2019 21:51:58 +0100 Message-ID: <87k1ev5rbl.fsf@tcd.ie> References: <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> <8736lkyewf.fsf@tcd.ie> <20190512155032.GC20053@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="86106"; 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 Sun May 12 23:08:12 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 1hPvhb-000MHL-HF for ged-emacs-devel@m.gmane.org; Sun, 12 May 2019 23:08:11 +0200 Original-Received: from localhost ([127.0.0.1]:47307 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPvha-0001Qb-ER for ged-emacs-devel@m.gmane.org; Sun, 12 May 2019 17:08:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPvgt-00010p-L2 for emacs-devel@gnu.org; Sun, 12 May 2019 17:07:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPvRy-0001s8-VL for emacs-devel@gnu.org; Sun, 12 May 2019 16:52:04 -0400 Original-Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]:39918) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hPvRy-0001k8-AR for emacs-devel@gnu.org; Sun, 12 May 2019 16:52:02 -0400 Original-Received: by mail-ed1-x541.google.com with SMTP id e24so14287583edq.6 for ; Sun, 12 May 2019 13:52:01 -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=bsQShKALbc4BI6+6iKSMLt9uFMc4gN0aZbfy+wbLDrk=; b=nGJAI8Ls9vw6ZHEgj8bawloYoGYNI1S39hOithqYPjCNowjyVV9i0t3h/KaI0uTEJB AlXNvba7OCY979rzOH02W7oIZ7J19NHRsBSzmMi9yuxkZzUzknvuC4UdJFUO/xsU6U30 d/T8rdeH21U1XvP/8DyAcb8z/BBvF5UkdiBbyZH9aXfKl4HmTD5lLdkiwraj2p3oa1py LrrajLYYUbp46UlaOeBNs97wtQvVdsCf9Lg2kIwNdHtbXUIQFUfh2WpGrTMB1TlNSoXJ ZVDGou66hDhYrTKkslXVsQ5GzBSQdybSxyFGPWn4KMX/rF02Kh+akXRywdoLySSGw5Gc ehpQ== 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=bsQShKALbc4BI6+6iKSMLt9uFMc4gN0aZbfy+wbLDrk=; b=BSU7LXExOZKLYXjLw+Zvb7RwI5kYMjTUJcNnwz//RrczpXu1KQMWhvNGaGfvm47vj0 71hOTKE9Iz3VH0BRo8NeRP5Sqsd3zdYX8OJvJsuaDWunPQr/RGpJhAqH1F67OAVh6ROm gogNza4WPLw2MSS47tLZSfjNx7KBgU3Oy5ef49eHzBccf8UjPbno2aL3WqT+Y/USpnah EWfiU9k2Vee1kTVxC3atzbHOSO/Ewsc+3bY7+FL1qo4jXGhDPb0aL95A7I0HxAKxxWEV 2hZAJYWaldGKjZ/Axci+utsUjtKYwyH1VpxRNMmb9CoJchH8kgQF52kmugCQxreuAE8P +kng== X-Gm-Message-State: APjAAAUZam3nR+tq//JQgKDuYDXgMyqvwk6lALg9lK9iOBuBPzxFrjoa cGzLXbV2OgVJTXxMc2BZqX5+8A== X-Google-Smtp-Source: APXvYqxFWEnAJrq0UJx/Tbz3fVyWjz4ljtFpJMCRADRJFTtkztgJZnZNO16Mnd5wqBtAECSmMMmUig== X-Received: by 2002:a17:906:c52:: with SMTP id t18mr19190903ejf.53.1557694320377; Sun, 12 May 2019 13:52:00 -0700 (PDT) Original-Received: from localhost ([2a02:8084:20e2:c380:8cad:ae29:555d:852d]) by smtp.gmail.com with ESMTPSA id d24sm3242718edb.5.2019.05.12.13.51.59 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 12 May 2019 13:51:59 -0700 (PDT) In-Reply-To: <20190512155032.GC20053@ACM> (Alan Mackenzie's message of "Sun, 12 May 2019 15:50:32 +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:236450 Archived-At: Alan Mackenzie writes: > On Sat, May 11, 2019 at 20:22:56 +0100, Basil L. Contovounesios wrote: >> Alan Mackenzie writes: > >> > 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. > > Is somebody requesting something? OK, clearly that is the case in a > merge request, but it's less clear for a "pull request". AFAIK, pull requests and merge requests are the same thing - the former term is used by GitHub, and the latter by GitLab (there could be some subtle difference, but IME they're effectively the same). > Is there also some name/process whereby somebody can submit a patch for > discussion, without the expectation it will be merged into master? Kind > of "I think this patch might be a good idea because ...., what do you > say?"? GitHub pull requests can be marked as "drafts" on creation (this is a relatively new feature), but I'm not sure if GitLab supports this yet. Either way, this is not an essential feature - there are other ways to convey the intention, e.g. by using a particular label or by using one's words. I've often seen people prepend their merge request titles with "[WIP]", for example. It's up to the maintainers and submitters to determine what kind of convention they want to follow, given GitLab's features. >> 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. > > Is the proposal here to allow an unauthenticated user to create forks on > the main server? This feels like a bad idea: how's moderation to be > done? I can imagine an arrangement not too dissimilar to Savannah: each submitter will first have to create an account on the GitLab instance. I'm not sure who will be administering this instance in practice, though, or how. One alternative would be cross-GitLab-instance merge requests, but a quick online search suggests this is not yet implemented: https://gitlab.com/gitlab-org/gitlab-ce/issues/1919 https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 https://gitlab.com/gitlab-org/gitlab-ce/issues/47191 >> >> 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. > > So, each "issue" has its own number, and the numbers of each merge > request associated with it. It seems to me that sometimes one number > will get used, sometimes another. (As happened in the aforementioned > proprietory system.) I'm not sure what makes you think that. Each number uniquely identifies a completely independent entity. If you want to refer to a particular issue, you use that issue's ID. If you want to refer to a particular merge request, you use that merge request's ID. You cannot refer to an issue by the ID of any associated merge requests, and vice versa. >> 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. > > I think the normal practice on Emacs, apart from for simple bugs, is for > somebody who isn't the author of the patch to close the bug, or at least > to confirm that it's fixed. The same practice can be followed using 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 doesn't sound like a good idea to me at the moment. If I write > "Fixes bug #123" into a commit message, that usually expresses an > intention rather than a conclusion. Surely closing bugs shouldn't happen > automatically, possibly by accident. IME it rarely happens by accident, and can be reversed when it does. GitLab can probably be configured to disable these features (in the future if not already). They are provided for convenience, so if they fail to be that can simply not be used. >> >> 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. > > OK. > >> Thanks, > > Thanks for the reply! Ditto. :) -- Basil