Re: [RFE] Migration to gitlab

[Eli Zaretskii <eliz@gnu.org>]

> From: 조성빈 <pcr910303@icloud.com>
> 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.