Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Alex Gramiak <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden
> Date: Fri, 10 May 2019 16:23:03 -0600
> 
> > So we must have a good support for a workflow that doesn't include any
> > pull/merge request at its beginning, maybe even never.
> 
> 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.

What interests me is which features make discussing an issue easier
than with debbugs.  What you describe above is in general identical to
how we do that on debbugs (except that there's no Web UI).

> 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). When the PR/MR is merged, any linked issues are
> 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 separation is IME not a good thing.  Integrated issue trackers
should have them both together.  I should be able to create a PR/MR
directly from the issue, or vice versa, instead of creating a new
object and then linking it to an old one.  But maybe in practice this
separation is not important enough to care about.