| 1 |
On 8/30/2013 4:52 AM, Sergey Popov wrote: |
| 2 |
> 29.08.2013 19:57, Andreas K. Huettel пишет: |
| 3 |
>> The braindead thing is that the GLSA is only going out after all |
| 4 |
arches have |
| 5 |
>> stabilized. |
| 6 |
>> |
| 7 |
>> Meaning, the slowest arch in practice blocks the GLSA process. |
| 8 |
>> |
| 9 |
> |
| 10 |
> We have security-supported arches list with arch teams liassons. When |
| 11 |
> they are all stabilized package, we can begin to make GLSA even if there |
| 12 |
> are other arches pending(e.g. s390/sh/m68k are NEVER considered |
| 13 |
> security-stable arches, per out docs[1]). However i think we should |
| 14 |
> reconsider this list, probably throw some arches away(and add some new, |
| 15 |
> for example arm, for which i can became security liasson). |
| 16 |
> |
| 17 |
> [1] - http://www.gentoo.org/security/en/vulnerability-policy.xml |
| 18 |
> |
| 19 |
The problem here is one of workflow. Even if we ignore |
| 20 |
security-unsupported arches, our workflow is generally bump packages -> |
| 21 |
stabilize -> clean up -> release GLSA -> close bug. The problem is that |
| 22 |
while we can skip ahead and start drafting a GLSA, we can't clean up and |
| 23 |
close the bug until the slow arches catch up on stabilizing, so they |
| 24 |
hold us up regardless. I'm all for changing the officially supported |
| 25 |
list, but I'm not sure how much good it will do us. |
| 26 |
|
| 27 |
Chris Reffett |
Archives