Hello, everyone. TL;DR: I'd like to propose that stabilizations are done via blockers of security bugs instead of security bugs themselves, i.e. as any other stabilizations.
Right now we're often performing security-related stabilizations via security bugs. This has a few problems, that are: 1. Stabilization-related activity causes unnecessary mail to the widely subscribed security alias. That is, subscribed people get notified of package list changes, NATTkA results, every arch doing its work. However, in reality the security team only cares about stabilization being started, stalled or finished -- and for that, getting the usual 'dependent bug added/closed' mail should be sufficient. 2. NATTkA has no good way of distinguishing irrelevant security bugs from security bugs where something went wrong (and NATTkA doesn't use persistent state by design). The most important problem is that -- unlike regular stablereqs -- security bugs aren't supposed to be closed after stabilization. It can't really distinguish a security bug 'left open' from a security bug with incorrect package list. 3. Proxied maintainers without editbugs can't actually CC arches on security bugs since the bugs are assigned to security@. To resolve these problems going forward and establish consistent behavior in the future, I'd like to propose to disable 'package list' fields on security bugs and instead expect regular stabilization bugs to be used (and made block the security bugs) for stabilizations. While I understand that filing additional bugs might be cumbersome for some people, I don't think it's such a herculean effort to outweigh the problems solved. In the end, consistency is a good thing and we've introduced a dedicated stabilization category to reduce the spread of stabilization bugs all around the place. WDYT? -- Best regards, Michał Górny
