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