Hi, >> It would be nice to be able to resolve the security@-assigned but >> before non-security-supported architectures are handled. >> >> To do that, I think we'd want to change what's required for the "clean >> up" step. Since today the "clean up" step is dropping the vulnerable >> package versions from the tree, it is dependent on >> non-security-supported architectures completing the stabilization bug. >> I think we'd like to break that dependence. >> >> I suggest that we redefine the "clean up" step to be: drop >> security-supported architectures' keywords from vulnerable versions. >> That would allow the security@-assigned bug to be resolved before >> non-security-supported architectures are finished with stabilization. >> > To be honest, this sounds like doubling the effort for little benefit. > After all, removing the old version of the package doesn't resolve any > problems on the end user systems -- upgrading does, and upgrading > usually happens entirely independently of whether we've cleaned up or > not. > > Maybe it'd easier to release GLSAs before cleanup happens? We can > always go the dekeywording way if arch teams are actually slacking. > I agree with both of you. In particular, cleaning old versions should not be a requirement for releasing the GLSA. The faster the GLSA can get out the better. Removing the keywords is a novel idea, but honestly not sure it's worth the effort.
Kind Regards, Jaco
