Re: [RFE] Migration to gitlab

[Alex Gramiak]

Eli Zaretskii <address@hidden> writes:

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

I'm not sure about features regarding the discussion itself (though
resolvable discussions[0] might be useful), but the administrative
aspect is (mostly*) more detailed and accessible than debbugs'. [1] is
an overview of issues, [2] is an overview of issue boards, [3] includes
a labeled picture of a typical issue page, and [4] describes the
crosslinking between issues/MRs.

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

This can be done (see number 18 in [3]).

> , or vice versa, instead of creating a new
> object and then linking it to an old one.

Typically one would create the issue first and make the MR later, and
FWIW Gitlab recommends[5] always doing that. Though if a stand-alone MR
turns out that it needs a more general discussion that warrants an
issue, then creating a new issue and linking the two is trivial and not
so different than creating a new thread in emacs-devel that references a
discussion on debbugs.

> But maybe in practice this separation is not important enough to care
> about.

I think that the separation works out in practice after getting used to
it, as long as there's not a plethora of separations like Alan
mentioned.


* Seems there's no "blocking issue" feature in Gitlab yet[6], but if the
  only use for this is release blocking, then using a milestone should be
  sufficient.

P.S. Another feature that would be nice is protected branches[7], which
I believe would allow for, e.g., release branches to be closed off for
commits (which was discussed recently), and for scratch branches to be
rebased (while disallowing rebasing for other branches).

[0]
https://docs.gitlab.com/ce/user/discussions/index.html#resolvable-comments-and-discussions

[1] https://docs.gitlab.com/ce/user/project/issues/

[2] https://docs.gitlab.com/ce/user/project/issue_board.html

[3]
https://docs.gitlab.com/ce/user/project/issues/issue_data_and_actions.html

[4]
https://docs.gitlab.com/ce/user/project/issues/crosslinking_issues.html

[5] https://about.gitlab.com/2016/03/03/start-with-an-issue/

[6] https://gitlab.com/gitlab-org/gitlab-ee/issues/2035

[7] https://docs.gitlab.com/ce/user/project/protected_branches.html