Ryan Scott
To identify backports I look at open tickets bearing the "backport needed" label.
That's good to know, thanks.
What should become of small MRs that are made directly against `master` (without a corresponding issue) that are intended to be backported as well? Does it suffice to label those with "backport needed", or should we also open "backport needed"–labeled issues as well to ensure that they're caught? (I have [1] and [2] in mind when asking this question.)
Indeed this is something I have wondered about. This is all a fair bit trickier recently because we currently are maintaining two "stable" branches (ghc-8.6 and ghc-8.8). This means that a MR could be in one of five states: a. ~"backport needed" applied and open: not present in master or any stable branch. b. ~"backport needed" applied and closed: present only in maser c. ~"backport needed" applied and closed: present in master and ghc-8.8 d. ~"backport needed" applied and closed: present in master and ghc-8.6 e. closed: present in master, ghc-8.8, and ghc-8.6 Unfortunately keeping track of which of (b), (c), or (d) an MR is in entirely manual. For this reason I have wondered whether it would be worth opening an issue for every backport request (e.g. for each backport MR that should be created). This sounds like it may be a lot of work but it would significantly reduce the probability that something is dropped on the floor (and address your quite valid concern of there being no way to view both issues and merge requests together). Cheers, - Ben