Re: [RFE] Migration to gitlab

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

[-- Attachment #1: Type: text/plain, Size: 4610 bytes --]


2019. 5. 11. 오전 11:12, Alan Mackenzie <acm@muc.de> 작성:

> Hello, Alex.
> 
>> On Fri, May 10, 2019 at 16:23:03 -0600, Alex Gramiak wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> My point was that an absolute majority of Emacs issues don't have a
>>> patch attached.  They describe a problem, and most of the reports
>>> don't even include a detailed analysis of the problem and its root
>>> cause.  A large part of discussing an issue is devoted to
>>> understanding the issue and then finding its cause.  Patches appear
>>> only after all that.
> 
>>> So we must have a good support for a workflow that doesn't include any
>>> pull/merge request at its beginning, maybe even never.
> 
> I don't know what "pull/merge request" means.  Does it mean a request by
> an outsider for a core contributor to perform a "git pull" operation
> from the outsider's computer, the outsider having opened up his machine
> to public access to allow this?

An outsider that is not a core contributor cannot make a new branch (as he/she doesn’t have enough authorization).
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).
Merging is also available in the command line; see https://gist.github.com/adam-p/15413fabef6cffecd897 ; but I’ve never seen anyone merging PRs like that in real life.

>> Gitlab et al. would provide that, IMO. When there's no PR/MR at the
>> beginning, the topic is submitted as an "Issue" and given a unique issue
>> number. However, patches aren't submitted to the issue: rather, a new
>> PR/MR is created, given a unique MR number, and is linked with the
>> relevant issue(s).
> 
> Yuck!  I recently worked with a proprietory system where each bug had
> several different numbers, an  issue number, an analysis number, a patch
> number, and so on.  It caused extra effort to keep track of bugs, and
> was generally horrible.

IIRC Gitlab uses one number for all ‘topic’s, but there are two types of topics(e.g. issue and PR). If you were annoyed that there are few types of different numbers, (e.g. Bug#71 and Analysis#71), GitLab is not the case.
There is only one #71 and it’s an issue or PR.

>> When the PR/MR is merged, any linked issues are closed.
> 
> You needn't have used the passive voice, there.  What does your sentence
> mean?  That when a user merges a PR/MR, gitlab automatically closes the
> issue (whether it's finished, or not)?  Or that a user can close an
> issue only after somebody has first merged at least one PR/MR?  Or
> something else?

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

> What is the point of issues and PR/MRs having distinct identifiers, if
> they are so tightly coupled with eachother?

As I mentioned before, they don’t have ‘distinct’ identifiers; any issue/PR can cross-reference other issue/PR with the number.

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.

If an core contributor fixed an issue, one doesn’t have to create a PR(as he/she already has commit; he/she can just mention the issue number in the commit message and it will be automatically closed.

>> This means that the discussion gets separated into two parts: the
>> discussion about the issue/problem (kept in the "Issues" category), and
>> the discussion about the patch/solution (kept in the "Merge Requests"
>> category).
> 
> This sounds like a Bad Thing to me.  It sounds rather like a workflow
> being imposed which imagines that first the bug gets "resolved"
> (whatever that means) in discussion, and only then does work start on a
> separate "merge request".  The above mentioned proprietory system was
> like this.  It didn't lend itself to a natural and efficient way of
> working.

No, one can interact with the bug while writing a patch and making a PR (or a commit). You can make a PR and continue to modify the PR (as the bug gets resolved?) until it becomes merged.

> -- 
> Alan Mackenzie (Nuremberg, Germany).
> 

[-- Attachment #2: Type: text/html, Size: 7144 bytes --]