Re: [RFE] Migration to gitlab

[Alan Mackenzie]

Hello, Basil.

On Sat, May 11, 2019 at 20:22:56 +0100, Basil L. Contovounesios wrote:
> Alan Mackenzie <address@hidden> writes:

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

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

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

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

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

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

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

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

> -- 
> Basil

-- 
Alan Mackenzie (Nuremberg, Germany).