[gentoo-dev] [RFC] Decoupling stabilization from security bugs

[Michał Górny]

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