Ben

I’m struggling to establish a clear understanding of the life cycle of an issue.

Consider https://gitlab.haskell.org/ghc/ghc/issues/15872.  Here is my faithfully recorded chain of thought at 2330 on a Tuesday night.

• I can see that it is closed
• But I wonder if it was fixed?
• Well, scrolling up from the bottom, apparently it was mentioned in no fewer than six patches.  That’s odd.  Why is this issue mentioned in six patches?
• Oh, one of those six patches is a dup, mentioned twice.  No idea why.
• Are any of the five The Patch that is designed to fix this issue.   Indeed does The Patch exist at all?  And what MR is it in?
• Oh, what is that MR?
• Hmm.  Well Ryan says “I’ve opened MR 851”.   Maybe that’s it?
• Let’s head over to MR 851: https://gitlab.haskell.org/ghc/ghc/merge_requests/851
• Oh! It just says “Closed”.  I was hoping it’d say “merged”, but no.
• Uh oh.  Near the top it says “Closed by Omer”... “the changes were not merged into master”.
• Then scrolling further down there is a lot of noise from Marge, followed by a presumably hand-written message from Omer saying “Merged as cc495d57.”.
• Huh.  So maybe it did get merged after all.

You can see how confused I am.   It all just feels like much more work to find relevant info than it should be.  It’s frustrating because all the info is in the system, -- it’s just hard (for me) to find.

An issue should say prominently: this is The MR (or MRs) that fixes the issue.

It should be easy to tell if those MR(s) have been successfully merged – along with their commit messages (this will come Moe Bot).

Trac used to let you close a ticket as “fixed” or “wont-fix” or “invalid” etc. This was Jolly Useful.  Doesn’t Gitlab?

Similarly, MRs sould be closed as “merged” or “abandoned”.

Much of this is not under your control – it’s what GitLab does.  But maybe we should have stronger best-practice guidelines.  Eg “Never just close an issue; always say “Closing as won’t fix” or...”.   etc. 

Simon