I would also love to know how to do this. I don't often contribute to GHC, but I follow bug fixes closely. In fact, the one time I did contribute ( https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10245), it turned out i was duplicating work already done elsewhere! If I had known how to understand if the issue I wanted fixed ( https://gitlab.haskell.org/ghc/ghc/-/issues/22516) was backported, it would have saved me and the maintainers' time.
On Wed, Sep 27, 2023 at 11:56 PM Bryan Richter via ghc-devs < ghc-devs@haskell.org> wrote: > I am not sure of the best ways for checking if a certain issue has been > fixed on a certain release. My past ways of using git run into certain > problems: > > The commit (or commits!) that fix an issue get rewritten once by Marge as > they are rebased onto master, and then potentially a second time as they > are cherry-picked onto release branches. So just following the original > commits doesn't work. > > If a commit mentions the issue it fixes, you might get some clues as to > where it has ended up from GitLab. But those clues are often drowning in > irrelevant mentions: each failed Marge batch, for instance, of which there > can be many. > > The only other thing I can think to do is look at the original merge > request, pluck out the commit messages, and use git to search for commits > by commit message and check each one for which branches contain it. But > then I also need to know the context of the fix to know whether I should > also be looking for other, logically related commits, and repeat the dance. > (Sometimes fixes are only partially applied to certain releases, > exacerbating the need for knowing the context.) This seems like a mechanism > that can't rely on trusting the author of the original set of patches > (which may be your past self) and instead requires a deep understanding to > be brought to bear every time you would want to double check the situation. > So it's not very scalable and I wouldn't expect many people to be able to > do it. > > Are there better mechanisms already available? As I've said before, I am > used to a different git workflow and I'm still learning how to use the one > used by GHC. I'd like to know how others handle it. > > Thanks! > > -Bryan > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs