Should issues be per vendor? How to handle a single vendor fix if the issue affects other vendors too?

[epilys]

Example case, #7 was opened in October 2023, today I found it on a specific vendor upstream who has since pushed a fix.

• There's a STATUS=FIXED label, but this seems semantically attached to the AFFECTED=* label
• This issue might be commonplace and other vendors can be identified in the future

Proposal

If someone wishes to report a new protocol behavior bug that is not a vendor-only implementation quirks (like GMAIL's unfortunate label <-> mailbox equivalence) and there's an already existing issue specifying the same bug with a different vendor specified as a label,

a new "parent" issue should be created that lists each related bug in its description. This way we can keep track of similar defects and track the status per vendor. The parent issue can stay closed as long as any sub-issues are closed.

Think of a "parent" issue as an abstract class in OOP or a.... category, it does not refer to vendors or current states (fixed/not fixed/reproduced), its only purpose is organizational and informative.

[duesee]

I think this could work. I'm not sure in general if issues + labels are really the best way for such a collection. Let's experiment a bit.

[epilys]

Yeah it might end up looking more like a database. Let's keep the current system while we think about it more?

[duesee]

Maybe we could use a version range? a.b.c ..= x.y.z? With a.b.c .. meaning "not fixed"?

And remove STATE=fixed for now?

[epilys]

for affected vendor? that'd been mean they can't be reused on other unrelated issues though.

[duesee]

Ugh... right.