GitLab cross-posting to Trac?

[Ben Gamari]

Richard Eisenberg <rae at cs.brynmawr.edu> writes:

> I second Simon's "super-helpful". But we don't need to exactly copy
> Trac's behavior. If there is a clear link to the e.g. commit with
> message, that's fine too.
>
>> On Jan 5, 2019, at 3:47 AM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
>> 
>> As from now all patches will be merged via gitlab it is unnecessary as
>> related merge requests
>
> We're not using GitLab ticketing yet, but I understand we will. When
> you say "related merge requests", does that include *issues*?
>
> GitHub does this, so I imagine it does, but we should make sure. In
> other words, if we make an MR that references an issue, will the issue
> show this fact? What if the MR text doesn't reference an issue, but
> the commit message does?

In both cases a note will be left on the referenced issue.

> For example, many of my patches are targeted toward one issue, but fix
> several others on the way. The MR text will probably mention only the
> main issue, but the commit message will mention the others. Will the
> others automatically be cross-referenced? Or will I be forced to copy
> these auxiliary issues into the MR text for proper cross-referencing?
>
> I believe in GitHub, the cross-referencing happens at *mentions*.

> I think that means we would get it upon posting the MR and upon the
> use of an issue number in a comment. But does anything happen at a
> *merge*? That is, suppose the fix for #12345 gets posted and debated
> at some length. The #12345 issue will get linked to the MR. Then, all
> is ready and we click the "merge when green" button. Some hours later,
> the MR is merged. Does the issue get updated then?
>
Yes, when the commit is merged to master a note of the form "mentioned
in commit abcde" will appear on the issue. The SHA is a link and the
commit title is shown when one hovers over it.

>> show up visually on each ticket and when a
>> patch is merge the ticket is automatically closed.
>
> By "ticket", do you mean issue or MR? I assume you mean MR, and I like
> this behavior. But I hope you don't mean issue. It's quite common to
> push a patch materially affecting an issue but not closing it, and I
> think the manual step to close the issue separately is worthwhile.
>
By default GitLab can automatically close issues mentioned by a commit
pushed to the `master` branch. However, not all mentioned will result in
closure; rather, only those matching one of a set of patterns [1].

I personally find the default set of patterns a bit scary. For instance,
I found that a commit containing the string "doesn't fix #NNNN" actually
results in #NNNN being closed [2]. For this reason I think we really want to
change or entirely disable [3] this behavior.

[1] https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html
[2] https://gitlab.com/gitlab-org/gitlab-ce/issues/55970
[3] https://docs.gitlab.com/ee/administration/issue_closing_pattern.html

>> Ticket numbers mentioned in commits also create references from
>> tickets to commits so you can click the hash to see what the commit
>> was.
>> 
>> https://gitlab.com/gitlab-org/gitlab-ce/issues/54621#note_129031655 <https://gitlab.com/gitlab-org/gitlab-ce/issues/54621#note_129031655>
>
> One small point of nomenclature I'd like to clarify/propose:
>
> - Merge Request (MR): A proposed patch. The new form of a Phab Diff.
> - Issue: An infelicity or task to be completed. The new form of a Trac Ticket.
> - Ticket: ?. I propose: Either an MR or an issue.
>
Hmm, I generally have used "ticket" and "issue" interchangeably. I
suppose we could repurpose it as you propose; I'm not sure which is less
confusing. In general I think I will probably just avoid using the term
after the migration.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190105/72aa8f1b/attachment.sig>