[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFE] Migration to gitlab

From: Basil L. Contovounesios
Subject: Re: [RFE] Migration to gitlab
Date: Sat, 11 May 2019 20:22:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Alan Mackenzie <address@hidden> writes:

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

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.

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.

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]