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:23:36 -0600 Message-ID: <8736lkikqf.fsf@gmail.com> 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> <83k1exec2n.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="197643"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: toon@iotcl.com, dgutov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 12 02:23:49 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 1hPcHN-000pIP-8b for ged-emacs-devel@m.gmane.org; Sun, 12 May 2019 02:23:49 +0200 Original-Received: from localhost ([127.0.0.1]:36854 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPcHM-00064I-8o for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 20:23:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPcHF-000649-M7 for emacs-devel@gnu.org; Sat, 11 May 2019 20:23:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPcHE-0007yJ-A3 for emacs-devel@gnu.org; Sat, 11 May 2019 20:23:41 -0400 Original-Received: from mail-pf1-x435.google.com ([2607:f8b0:4864:20::435]:43385) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hPcHE-0007xe-0b; Sat, 11 May 2019 20:23:40 -0400 Original-Received: by mail-pf1-x435.google.com with SMTP id c6so5164800pfa.10; Sat, 11 May 2019 17:23:39 -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=eTvRaf/MGuItyhn1hf6nXiIH9KS6TGxlDpTB7YTeh2U=; b=NRgtkeRztLPtluwuXVFlPJkXtEhoO02E2qb7+xVX+VtHmsE9ead9B6xOQmtlzmpjt9 0tp77iGwGx5kuOdsZD4oxMWEP44gex+Kf9pcNI9fGzPamz3wYT/PIZ941wQ0WIDO/tGK N239ZGNhPc693wrEYgats07nEzANg+8cAU8NkUr1c15nzy/PR2tbKrhfL1M5FYCyYpz0 0aNMpjoqac7Qkmtm9QWRSfDP+mrf6+OvCPeOYyE2gEyYNnmHEMXy+fTAlUxkCAdsdCAT 0B2fh+kCMWvl9pXCo3MvRUTNgdP6GusJh4p/UrXmN2QyEpIQHHGYur3gurLJM6e+yujB 5VkA== 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=eTvRaf/MGuItyhn1hf6nXiIH9KS6TGxlDpTB7YTeh2U=; b=ftyo9Tbolr0yO5X71mpxwzOldPTUlGAkYZaROpkAufUWuWRb213CnWivBgueBeCTiz cYM5ZFBjQkjgYwd52Zq/+zWpeyGS1G7yPVF/DHqpPPfCrTevOWB18hAfBbwsK1x8buhS LHhXMd8/IEogFnLzQRGJBZjpaESEWuihWsKK5V5kBplTobUF003hfoQuqnrVFTZX3IPU vBNr0GQZBUvNpZqnYzBcOhiCzwp2S5L1uTB47zhu8Wj+0SoYWmX4DlI34jYwxw+ILUbs 6sPSBR+7TKiYM7V+qwIkx6u18PxJzmDuV2+ObVklSzA2EMoC5Jhga3NvW4RibV0I1J/B ZgNQ== X-Gm-Message-State: APjAAAXYwSDCwCFuZtkqVxsS/PEuI0fRhJOR/l1gpRthL/oxsftQ0w4I 9RLO2YnRtDmL94m47PT1ISo= X-Google-Smtp-Source: APXvYqwbXKg4rDD7AUfZaySjFM0GB4zlrU+XKjagLz241QQ41C/WXtdYyHL7ETvpm6TLkMrydEK6Lg== X-Received: by 2002:a62:864a:: with SMTP id x71mr25509197pfd.228.1557620617633; Sat, 11 May 2019 17:23:37 -0700 (PDT) Original-Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id m123sm16829809pfm.39.2019.05.11.17.23.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 11 May 2019 17:23:36 -0700 (PDT) In-Reply-To: <83k1exec2n.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 May 2019 09:32:00 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::435 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:236443 Archived-At: Eli Zaretskii writes: >> 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). I'm not sure about features regarding the discussion itself (though resolvable discussions[0] might be useful), but the administrative aspect is (mostly*) more detailed and accessible than debbugs'. [1] is an overview of issues, [2] is an overview of issue boards, [3] includes a labeled picture of a typical issue page, and [4] describes the crosslinking between issues/MRs. >> 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 This can be done (see number 18 in [3]). > , or vice versa, instead of creating a new > object and then linking it to an old one. Typically one would create the issue first and make the MR later, and FWIW Gitlab recommends[5] always doing that. Though if a stand-alone MR turns out that it needs a more general discussion that warrants an issue, then creating a new issue and linking the two is trivial and not so different than creating a new thread in emacs-devel that references a discussion on debbugs. > But maybe in practice this separation is not important enough to care > about. I think that the separation works out in practice after getting used to it, as long as there's not a plethora of separations like Alan mentioned. * Seems there's no "blocking issue" feature in Gitlab yet[6], but if the only use for this is release blocking, then using a milestone should be sufficient. P.S. Another feature that would be nice is protected branches[7], which I believe would allow for, e.g., release branches to be closed off for commits (which was discussed recently), and for scratch branches to be rebased (while disallowing rebasing for other branches). [0] https://docs.gitlab.com/ce/user/discussions/index.html#resolvable-comments-and-discussions [1] https://docs.gitlab.com/ce/user/project/issues/ [2] https://docs.gitlab.com/ce/user/project/issue_board.html [3] https://docs.gitlab.com/ce/user/project/issues/issue_data_and_actions.html [4] https://docs.gitlab.com/ce/user/project/issues/crosslinking_issues.html [5] https://about.gitlab.com/2016/03/03/start-with-an-issue/ [6] https://gitlab.com/gitlab-org/gitlab-ee/issues/2035 [7] https://docs.gitlab.com/ce/user/project/protected_branches.html