GitLab cross-posting to Trac?

[Simon Peyton Jones]

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 <rae at cs.brynmawr.edu>
Sent: 05 January 2019 16:15
To: Matthew Pickering <matthewtpickering at gmail.com>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; Ben Gamari <ben at smart-cactus.org>; GHC <ghc-devs at haskell.org>
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 <matthewtpickering at gmail.com<mailto: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? 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_129031655<https://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
<ghc-devs at haskell.org<mailto:ghc-devs at 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 <ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>> On Behalf Of Ben Gamari
| Sent: 04 January 2019 21:33
| To: Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>>; GHC <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
| Subject: Re: GitLab cross-posting to Trac?
|
| Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at 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 at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190105/a44ebf3b/attachment.html>