I really don't think we should emulate trac's behaviour here. As from now all patches will be merged via gitlab it is unnecessary as related merge requests show up visually on each ticket and when a patch is merge the ticket is automatically closed. 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 On Sat, Jan 5, 2019 at 1:31 AM Simon Peyton Jones via ghc-devs wrote:

It's **super-helpful** that the Trac ticket includes, as a comment, the commit(s) that fixed it. Please can this happen with Gitlab too?

Otherwise, when looking at the ticket two years later there is literally no clue what commit (if any) fixed it.

If it can't be done automatically, it must be done manually by each person making a commit. Which is terribly painful. (esp since it can only be done post-CI.)

Thanks

Simon

| -----Original Message----- | From: ghc-devs On Behalf Of Ben Gamari | Sent: 04 January 2019 21:33 | To: Richard Eisenberg ; GHC | Subject: Re: GitLab cross-posting to Trac? | | Richard Eisenberg writes: | | > Hi devs, | > | > With our new GitLab workflow, will commit messages still be posted to | > Issues (once the migration is complete)? That's been really useful | > with Trac. | > | GitLab does not post the commit message to the issues it mentions. It | does create a link to the commit but this doesn't include the commit | message. We could change this with a daemon if we think this would be | helpful. | | Cheers, | | - Ben

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Thanks Richard - you have put it better than me. It would be v helpful to have a wiki page summarising all this vocabulary, and how and under what circumstances one thing refers to another. Simon From: Richard Eisenberg Sent: 05 January 2019 16:15 To: Matthew Pickering Cc: Simon Peyton Jones ; Ben Gamari ; GHC Subject: Re: GitLab cross-posting to Trac? 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 mailto:matthewtpickering@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? 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? 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. 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_129031655https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fgitlab-org%2Fgitlab-ce%2Fissues%2F54621%23note_129031655&data=02%7C01%7Csimonpj%40microsoft.com%7Cafe22b92b7f340e8be9c08d673295f3a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636823018866115712&sdata=7qFHHV7WwJeNFDRDMP15mU%2BIklGLoso%2BZNorprnD6lU%3D&reserved=0 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. Thanks! Richard On Sat, Jan 5, 2019 at 1:31 AM Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org> wrote: It's **super-helpful** that the Trac ticket includes, as a comment, the commit(s) that fixed it. Please can this happen with Gitlab too? Otherwise, when looking at the ticket two years later there is literally no clue what commit (if any) fixed it. If it can't be done automatically, it must be done manually by each person making a commit. Which is terribly painful. (esp since it can only be done post-CI.) Thanks Simon | -----Original Message----- | From: ghc-devs mailto:ghc-devs-bounces@haskell.org> On Behalf Of Ben Gamari | Sent: 04 January 2019 21:33 | To: Richard Eisenberg mailto:rae@cs.brynmawr.edu>; GHC mailto:ghc-devs@haskell.org> | Subject: Re: GitLab cross-posting to Trac? | | Richard Eisenberg mailto:rae@cs.brynmawr.edu> writes: | | > Hi devs, | > | > With our new GitLab workflow, will commit messages still be posted to | > Issues (once the migration is complete)? That's been really useful | > with Trac. | > | GitLab does not post the commit message to the issues it mentions. It | does create a link to the commit but this doesn't include the commit | message. We could change this with a daemon if we think this would be | helpful. | | Cheers, | | - Ben _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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