Re: [RFE] Migration to gitlab

[조성빈]

2019. 5. 11. 오전 11:12, Alan Mackenzie <address@hidden> 작성:

Hello, Alex.

On Fri, May 10, 2019 at 16:23:03 -0600, Alex Gramiak wrote:

Eli Zaretskii <address@hidden> 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).