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 13:02:09 +0300 Message-ID: <83bm09e2ce.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> <83ef55eapl.fsf@gnu.org> 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="236232"; 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 12:02:34 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 1hPOpt-000zHW-Lw for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 12:02:33 +0200 Original-Received: from localhost ([127.0.0.1]:56671 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPOps-0000iw-Nn for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 06:02:32 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPOph-0000im-30 for emacs-devel@gnu.org; Sat, 11 May 2019 06:02:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPOpb-0001mC-Qk; Sat, 11 May 2019 06:02:17 -0400 Original-Received: from [176.228.60.248] (port=2953 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hPOpZ-0006Na-W7; Sat, 11 May 2019 06:02:15 -0400 In-reply-to: (message from =?utf-8?B?7KGw7ISx67mI?= on Sat, 11 May 2019 16:38:30 +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:236411 Archived-At: > From: 조성빈 > Date: Sat, 11 May 2019 16:38:30 +0900 > Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru, > acm@muc.de, toon@iotcl.com, agrambot@gmail.com > > > 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.? > > I’m not sure about what ‘log messages’ mean. Commit log messages. > If you’re saying commit messages, you can view them and ask the contributors to fix the messages, rebase the commits, and force-push them. You can merge them afterwards. Asking the contributors to fix the log messages works only up to some not very far limit. Quite frequently, IME, the 2nd, the 3rd, and sometimes the 4th attempt are still not what I'd like to see, whether due to misunderstanding or something else. At which point I usually give up and fix the rest myself, so as not to discourage the contributor the next time he/she wants to contribute. Force-push is normally not an option, as our repository disallows that, to avoid someone's mistake corrupting the repository or losing data. So there should be an easy way of accepting a PR/MR where I can augment the log message in the process. Because once the commit is pushed, whatever deficiencies there were in the log message are carved in stone forever. > And yes, GitLab adds the reference to the issue, which commit or PR resolves this issue. What if the issue is not yet resolved, like when we commit a change that fixes only part of the issue, or is only tangentially related to it? We cannot yet close the issue, but a reference to it should be in the commit log. > About adding the copyright/paperworks, there isn’t a default setting, but you can have a bot to do that. I’ve never used one myself, so I’m not sure, but I’ve seen lots of projects that use bots to get paperwork, etc... How can a bot do that, when a commit log message is immutable once the commit is pushed? Anyway, the above are all bread and butter of core developers' work when we accept contributions. If we are to migrate to another platform, that platform should help us in these areas, or at least not make them less convenient. Support for those aspects should be part of evaluating the alternatives, IMO. > > 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". > > Mentioning (and closing) issues in commit messages/PR messages are completely optional; If you feel that this commit or PR fix shouldn’t close the issue, you just don’t have to mention the issue, and ask the issue reporter check if the commit/PR fixes the particular issue, etc... See above: sometimes the issue _should_ be mentioned, even though it isn't yet closed by a commit. > We don’t mix commits with issues :-) I think we do, and we should.