Re: [RFE] Migration to gitlab

["Basil L. Contovounesios" <contovob@tcd.ie>]

Alan Mackenzie <acm@muc.de> writes:

> On Sat, May 11, 2019 at 20:22:56 +0100, Basil L. Contovounesios wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > 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?
>
>> A {pull,merge} request is a diff of two Git branches for which the issue
>> tracker cum Git forge (GitLab) creates a dedicated ticket with which
>> ensuing discussion and other metadata is associated.  In simplistic
>> terms, it's like an interactive set of patches.
>
> Is somebody requesting something?  OK, clearly that is the case in a
> merge request, but it's less clear for a "pull request".

AFAIK, pull requests and merge requests are the same thing - the former
term is used by GitHub, and the latter by GitLab (there could be some
subtle difference, but IME they're effectively the same).

> Is there also some name/process whereby somebody can submit a patch for
> discussion, without the expectation it will be merged into master?  Kind
> of "I think this patch might be a good idea because ...., what do you
> say?"?

GitHub pull requests can be marked as "drafts" on creation (this is a
relatively new feature), but I'm not sure if GitLab supports this yet.
Either way, this is not an essential feature - there are other ways to
convey the intention, e.g. by using a particular label or by using one's
words.  I've often seen people prepend their merge request titles with
"[WIP]", for example.  It's up to the maintainers and submitters to
determine what kind of convention they want to follow, given GitLab's
features.

>> The two branches in question are: (1) the branch containing the
>> submitter's proposed changes, and (2) the upstream branch these changes
>> are intended to be merged into.
>
>> The two branches can live either in the same repository, or in separate
>> "forks" (copies) of the same repository.  The former case means that the
>> submitter already has push access to the centralised upstream
>> repository.  The latter case is more common for first-time and
>> infrequent contributors who do not have push access, and thus have no
>> option but to create their merge requests (patch sets) against their
>> personal fork/copy/checkout of the upstream repository.
>
> Is the proposal here to allow an unauthenticated user to create forks on
> the main server?  This feels like a bad idea: how's moderation to be
> done?

I can imagine an arrangement not too dissimilar to Savannah: each
submitter will first have to create an account on the GitLab instance.
I'm not sure who will be administering this instance in practice,
though, or how.

One alternative would be cross-GitLab-instance merge requests, but a
quick online search suggests this is not yet implemented:

https://gitlab.com/gitlab-org/gitlab-ce/issues/1919
https://gitlab.com/gitlab-org/gitlab-ce/issues/4013
https://gitlab.com/gitlab-org/gitlab-ce/issues/47191

>> >> 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.
>
>> Each bug report ("issue") has only a single number.  Similarly each
>> merge request has only a single number.
>
> So, each "issue" has its own number, and the numbers of each merge
> request associated with it.  It seems to me that sometimes one number
> will get used, sometimes another.  (As happened in the aforementioned
> proprietory system.)

I'm not sure what makes you think that.  Each number uniquely identifies
a completely independent entity.  If you want to refer to a particular
issue, you use that issue's ID.  If you want to refer to a particular
merge request, you use that merge request's ID.  You cannot refer to an
issue by the ID of any associated merge requests, and vice versa.

>> Merge requests are often submitted to address an existing issue, in
>> which case the relevant Git commit messages and/or merge request
>> description canonically contain a textual reference to this issue.  But
>> it is up to the submitter and/or reviewers to ensure such a reference
>> is mentioned somewhere; the UI does not force it upon anyone.
>
>> >> 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?
>
>> > What is the point of issues and PR/MRs having distinct identifiers, if
>> > they are so tightly coupled with eachother?
>
>> They are not that tightly coupled to each other.  Issues and merge
>> requests can be opened and closed independently of one another and in
>> any order, and each issue needn't be associated with a merge request,
>> and vice versa.  Even if they are associated, this association is mostly
>> implicit in the text of the discussion, not something imposed by GitLab.
>
> I think the normal practice on Emacs, apart from for simple bugs, is for
> somebody who isn't the author of the patch to close the bug, or at least
> to confirm that it's fixed.

The same practice can be followed using GitLab.

>> As mentioned elsewhere in this thread, however, GitLab can automatically
>> take certain known actions based on specially crafted command phrases
>> included as part of commit messages or discussion comments, for
>> convenience.  For example, if a merge request contains a commit which
>> includes the phrase "Fixes #123", then merging the merge request
>> (i.e. merging its constituent commits into the upstream branch) causes
>> GitLab to automatically close bug number 123.  Similarly including an
>> automatically stripped command such as "/close" in a comment causes its
>> issue or merge request to be closed.
>
> This doesn't sound like a good idea to me at the moment.  If I write
> "Fixes bug #123" into a commit message, that usually expresses an
> intention rather than a conclusion.  Surely closing bugs shouldn't happen
> automatically, possibly by accident.

IME it rarely happens by accident, and can be reversed when it does.
GitLab can probably be configured to disable these features (in the
future if not already).  They are provided for convenience, so if they
fail to be that can simply not be used.

>> >> 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.
>
>> The workflow is mostly up to the maintainers to design.  Issues and
>> merge requests are independent entities - one mustn't come before the
>> other.  The only difference is that issues are discussion-only (though
>> code snippets and diffs can of course be included as part of a comment,
>> and can even be prettified with syntax highlighting in the web UI),
>> whereas merge-requests additionally contain a realtime comparison of the
>> current state of two Git branches, and allow interactive commenting on
>> specific lines of the diff.  How issues and merge requests are used,
>> linked, labelled, etc. is up to the maintainers.
>
> OK.
>
>> Thanks,
>
> Thanks for the reply!

Ditto. :)

-- 
Basil