Re: [RFE] Migration to gitlab

[Eli Zaretskii]

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

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