Re: [RFE] Migration to gitlab

[Alan Mackenzie]

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?

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

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).