Re: [RFE] Migration to gitlab

[조성빈 <pcr910303@icloud.com>]

2019. 5. 11. 오후 4:01, Eli Zaretskii <eliz@gnu.org> 작성:

>> From: 조성빈 <pcr910303@icloud.com>
>> Date: Sat, 11 May 2019 12:47:27 +0900
>> Cc: Alex Gramiak <agrambot@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>> 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.?

I’m not sure about what ‘log messages’ mean.
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.
And yes, GitLab adds the reference to the issue, which commit or PR resolves this issue.
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... 

>> 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".

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...

>> 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.

Think as a PR a commit that needs authorization; We don’t mix commits with issues :-)