Keeping track of issues

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Keeping track of issues

GHC - devs mailing list

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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Keeping track of issues

Ömer Sinan Ağacan
Hi Simon,

> 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?

That's because Marge got stuck for some reason (I think related to but in Gitlab
API, but I'm not sure) and couldn't merge the first batch MR that it created.
So it created another one, failed again, created another one and so on. The
MR you're looking at was in those batch MRs, so every time Marge created another
MR the issue you're looking at got a new reference.

After 6 attempts by Marge I realized that it got stuck for good so I stopped it,
merged the last batch MR crated by Marge manually, closed all other MRs in that
batch MR with a "merged as ..." comment, and started Marge again.

> Oh, one of those six patches is a dup, mentioned twice.  No idea why.

I think you mean cc495d57 ? I'm not sure why it's mentioned twice, perhaps it's
a Gitlab bug. I'd only expect to see "closed via cc495d57", "mentioned in
cc495d57" looks redundant to me after that.

> 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?

There's just one patch. The commit hash is different for each one becuase
they're applied to a different tree in each MR.

> Hmm.  Well Ryan says “I’ve opened MR 851”.   Maybe that’s it?

That's the original MR that fixed the issue. All other MRs are batch merge
request created by Marge.

> Oh! It just says “Closed”.  I was hoping it’d say “merged”, but no.

> 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.”.

I also don't understand this part. Normally when Marge merges a MR similar to
how I merge, the MR gets a "merged" comment, but when I merged the batch MR
manually this did not happen, so I added a "merged as ..." comment to each MR
that I merged and closed the MRs.

> Huh.  So maybe it did get merged after all.

Right.

Reading rest of your email, I think the main issues are:

- Marge gets stuck for various reasons and generates a lot of noise
until someone
  intercepts. (this is why you saw all those commit references in the issue and
  Marge comments in the fixing MR)

- (This may be a mistake on my part) When I merged a batch of merge requests
  manually those merge requests are not automatically closed.

- There's no way to close a MR as "merged" unless Gitlab decides that it's
  merged. So in my case I couldn't close those MRs as "merged" and had to close
  as "closed".

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

I think the Gitlab way of closing something as "wont-fix" is by labelling it as
"wont-fix" and then closing the ticket/MR.

Ömer

Simon Peyton Jones via ghc-devs <[hidden email]>, 8 May 2019
Çar, 01:36 tarihinde şunu yazdı:

>
> 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
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs