Re: [RFE] Migration to gitlab

[Alex Gramiak]

Hi, Alan.

Alan Mackenzie <address@hidden> writes:

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

Typically a local copy of the repository is uploaded somewhere else so
that the server can access the branch. Outsiders should be able to make
an account on a hypothetical GNU Gitlab instance, push their repository
to their account, and then have the MR be between that repository and
the upstream in the GNU Gitlab instance. For example, [1] (under Using a
fork - Non GNOME developer) describes how this process works for
outsiders for the GNOME project.

Basil gave a good description of pull/merge requests, but here[2] is an
example picture of a merge request in the Gitlab web UI.

The main body consists of a topic and MR comment, which includes several
sections in Markdown and a special phrase "Closes #46869" that will
automatically close issue #46869 when the MR is accepted. The phrase can
also occur in a commit message instead of the MR message.

The right sidebar includes some metadata like the assignee, milestone,
labels, and participant list.

Below the comment is the status of the MR. Below that is the discussion,
list of commits, the pipelines[3], and the diff of the MR.

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

That indeed sounds awful, but IMO the Gitlab style is different as there
are only two categories, with the bug (an issue) having a single ID, and
a set of MRs containing separate IDs. Keeping track of bugs would
usually just involve using the issue number, not the MR number.

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

Only if the submitter (or merger if the server allows) specifies that
the MR closes the issue. See [4] for how Gitlab handles this.

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

To reiterate what Basil said, it's up to the maintainers in how MRs
would be used (though too significant of a departure from the standard
would detract from the newcomer-friendly aspect of this move). All
discussion could be in the issue with no comments in the MR outside of
comments specifically about the implementation of the MR.

I can see how the workflow could include some aspects that might be
somewhat unnatural/inefficient (such as a discussion about the bug in
the MR that has to be summarized/duplicated/linked in the issue), but I
don't think that it's much of a deal in this type of system. As with any
system, a certain class of workflows is imposed, but this system, while
encouraging a thorough discussion on the issue side first, can still
have MR(s) being worked on while the discussion in the issue is ongoing.
It's just that the discussion for the MR is separated from the issue at
large. One can think of the MR discussion as a separate email subthread
for the main/issue thread.

[1] https://wiki.gnome.org/GitLab

[2]
https://docs.gitlab.com/ee/user/project/merge_requests/img/merge_request.png

[3] https://docs.gitlab.com/ee/ci/pipelines.html


[4] https://docs.gitlab.com/ce/user/project/issues/automatic_issue_closing.html