In bugzilla, we would sometimes use a “meta-bug” to identify a bunch of issues on a given topic, and the other bugs would be marked as blocking the meta-bug. This didn’t directly propagate to GitHub; the meta-bugs still exist, and the list of blockers is textually there in the meta-bug (see for example issue 37076) but GitHub doesn’t seem to have a “blocker” mechanism the way Bugzilla does.
We can implicitly link two issues by mentioning one in a comment on the other; is that good enough? Or would a label be more the thing to do?
There are multiple ways of doing so depending on the scope. For example, currently we’re using milestones for tracking release-specific issues instead of release “meta-bugs”.
For different cases we may use:
- Labels (I’d say this is the last resort, say, for meta-bugs that might be around forever)
You can also use task lists.
In the cases I’m interested in, the meta-bug probably will be around forever; they are
issue 37076, bugs where adding -g causes some kind of codegen change
issue 30616, bugs where optimization results in poor debug info
issue 38116, bugs reporting poor debugging experiences
Yeah, I think those all seem more suited to labels, probably (even in Bugzilla that might’ve been the better option than a metabug that’s never going to be closed)? But I’m not especially familiar with github issues