Re: [RFE] Migration to gitlab

[조성빈]

2019. 5. 11. 오후 4:01, Eli Zaretskii <address@hidden> 작성:

>> From: 조성빈 <address@hidden>
>> Date: Sat, 11 May 2019 12:47:27 +0900
>> Cc: Alex Gramiak <address@hidden>, Eli Zaretskii <address@hidden>,
>> address@hidden, address@hidden, address@hidden,
>> address@hidden
>> 
>> 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 :-)