Keeping track of issues

Simon Peyton Jones simonpj at microsoft.com
Tue May 7 22:36:11 UTC 2019


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</ghc/ghc/commit/cc495d5777c01ef62129df15caacf87b0e430c6b>.".
  *   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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190507/cf8acfc1/attachment.html>


More information about the ghc-devs mailing list