Richard Eisenberg
Thanks to all who have made this happen. Looking forward to having everything in one place!
Do we have any ability to edit the formatting of subject lines of ticket emails? It would be great if we could get the (!234) or (#12345) up front, as this is the effective summary of what's to follow.
I think we can manage that. Ideally I'd like to stay as close to an unmodified GitLab installation as possible but this particular issue doesn't sound like it should be a hard thing to fix.
I'd also like to second Simon's request, in particular, of having a clear path from an issue to an MR. Getting from an MR to an issue is normally easier -- when the MR is created, most devs would automatically mention the issue number somewhere in the description -- but going from an issue to an MR is harder. It would be a shame to have to search through the commentary looking for the link. I used the old "Phab:D1234" links in the top of a Trac ticket quite often.
In principle it shouldn't be any harder to go from an issue to an MR than it is to go the other direction. For instance, consider the case of #16347 [1]. You will note that below the "Related issues" section there is a list of related merge requests (strangely formatted completely differently). To be honest, how this list is formed is a bit of a mystery to me. The fact that !525 is included is not surprises: !525 mentions #16347 in its description. However, !436 is a bit less obvious since it does not mention #16347 at all. My hypothesis is that it is transitively included via #16344, which does mention #16437 and is related to it. [1] https://gitlab.haskell.org/ghc/ghc/issues/16347
I also second the request for a test-case field. This field, to me, is most useful as a reminder to the author that they need to add a test case. But I think the issue-to-MR link is more important than the test-case field.
Indeed, as I mentioned earlier this may be a bit of a hard thing to accomplish in the near-term. One measure we could take to ensure that tests aren't forgotten is to include a "field" in the default merge request description which contributors would be asked to fill in with the names of the tests that cover their change. That being said, this is no substitute for a proper field. Cheers, - Ben