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 10:01:26 +0300 Message-ID: <83ef55eapl.fsf@gnu.org> 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; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="268712"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru, acm@muc.de, toon@iotcl.com, agrambot@gmail.com To: =?utf-8?B?7KGw7ISx67mI?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 11 09:01:45 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 1hPM0v-0017gI-JA for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 09:01:45 +0200 Original-Received: from localhost ([127.0.0.1]:55270 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPM0u-00077g-Ja for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 03:01:44 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPM0k-00077P-Ux for emacs-devel@gnu.org; Sat, 11 May 2019 03:01:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPM0i-0000Pt-6P; Sat, 11 May 2019 03:01:32 -0400 Original-Received: from [176.228.60.248] (port=2820 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hPM0h-0001Rz-Fb; Sat, 11 May 2019 03:01:31 -0400 In-reply-to: (message from =?utf-8?B?7KGw7ISx67mI?= on Sat, 11 May 2019 12:47:27 +0900) 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:236409 Archived-At: > From: 조성빈 > Date: Sat, 11 May 2019 12:47:27 +0900 > Cc: Alex Gramiak , Eli Zaretskii , > emacs-devel@gnu.org, toon@iotcl.com, monnier@iro.umontreal.ca, > dgutov@yandex.ru > > So the outsider can ‘fork’ the repo, to make an exact clone of it, push his/her changes(commits) to GitLab, > and make a merge request. The pull/merge request is a request the core contributor to ‘pull’ the changes of > the forked repo and ‘merge’ it just as if the forked repo is just another branch. > This can be done by just clicking a button to merge(in the web UI). Does "clicking a button" take care of various minor details I frequently need to do when applying patches from random contributors, such as fixing the log messages (or providing them in the first place), adding a reference to the bug/issue, adding the Copyright-paperwork-exempt tag, etc.? > When the core contributor decides that the PR is done and merges it to the main repo, GitLab automatically > closes the issue. (If the PR was found to be an incomplete solution, the issue can be re-opened.) We currently have the opposite situation: pushing a fix doesn't automatically close the issue. Both are bad as defaults, because IME what needs to be done is split roughly 50%. So a much better UI would be to force the user to check a box when "clicking the merge button". > If you’re saying what’s the point of having two types of topics(issues and PRs), it’s that PRs are primarily a > way to put code, while issues are primarily a way to report bugs, feature requests. There's no such distinction in practice, it is a purely artificial thing. There should be only one category, whether there is or isn't a PR. But I don't think this aspect should be of any significant importance, it's just a fluke to get used to.