| 1 |
On Fri, Aug 30, 2013 at 08:53:38AM -0400, Chris Reffett wrote: |
| 2 |
> On 8/30/2013 4:52 AM, Sergey Popov wrote: |
| 3 |
> > 29.08.2013 19:57, Andreas K. Huettel пишет: |
| 4 |
> >> The braindead thing is that the GLSA is only going out after all |
| 5 |
> arches have |
| 6 |
> >> stabilized. |
| 7 |
> >> |
| 8 |
> >> Meaning, the slowest arch in practice blocks the GLSA process. |
| 9 |
> >> |
| 10 |
> > |
| 11 |
> > We have security-supported arches list with arch teams liassons. When |
| 12 |
> > they are all stabilized package, we can begin to make GLSA even if there |
| 13 |
> > are other arches pending(e.g. s390/sh/m68k are NEVER considered |
| 14 |
> > security-stable arches, per out docs[1]). However i think we should |
| 15 |
> > reconsider this list, probably throw some arches away(and add some new, |
| 16 |
> > for example arm, for which i can became security liasson). |
| 17 |
> > |
| 18 |
> > [1] - http://www.gentoo.org/security/en/vulnerability-policy.xml |
| 19 |
> > |
| 20 |
> The problem here is one of workflow. Even if we ignore |
| 21 |
> security-unsupported arches, our workflow is generally bump packages -> |
| 22 |
> stabilize -> clean up -> release GLSA -> close bug. The problem is that |
| 23 |
> while we can skip ahead and start drafting a GLSA, we can't clean up and |
| 24 |
> close the bug until the slow arches catch up on stabilizing, so they |
| 25 |
> hold us up regardless. I'm all for changing the officially supported |
| 26 |
> list, but I'm not sure how much good it will do us. |
| 27 |
|
| 28 |
Well, dropping an arch from the GLSA list is a far less drastic option, and |
| 29 |
afaict from your description, would answer the concerns of long stabilisation |
| 30 |
queues for devs on faster-moving archs, working on popular/volatile packages. |
| 31 |
|
| 32 |
Perhaps that could be automated, with whatever timeframe QA blesses, and |
| 33 |
act as a prelude or interim measure; either the arch goes unstable eg 6 or |
| 34 |
12 months later or it shows it can keep up with GLSAs. That gives the team |
| 35 |
enough time to either recruit, or taper down their workload, without losing |
| 36 |
the work they've put in. The demoralisation effect of the latter is too |
| 37 |
serious to ignore, especially for already-undermanned teams. |
| 38 |
|
| 39 |
Under this view, if you don't have enough semi-skilled users interested |
| 40 |
enough to help out with GLSAs, and can't get them in say 6 months, you don't |
| 41 |
have enough developers to stay stable, but still have time to warn your users, |
| 42 |
and wind-down after making the decision. Meantime, some of them might take |
| 43 |
it as a wake-up call, and pitch in. |
| 44 |
|
| 45 |
Regards, |
| 46 |
steveL. |
| 47 |
-- |
| 48 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |
Archives