Rapid release for security updates

[Ralf Corsepius]

On 05/26/2015 06:22 PM, Stephen Gallagher wrote:
> On Tue, 2015-05-26 at 15:33 +0200, Ralf Corsepius wrote:
>> On 05/26/2015 12:10 PM, Andrew Haley wrote:
>>>   Something needs to be done, but I'm not sure
>>> exactly what.
>>
>> IMO, all this should not be a problem, if collaborative maintenance
>> works.
>>
>> What I mean, IMO, critical packages should have a sufficient number
>> of
>> co-maintainers, who should be presumed to be sufficiently familiar
>> with
>> a package to provide enough karma, which would allow such packages to
>>
>> pass quickly.
>>
>
>
> That might work for comparatively simple packages, but what about the
> kernel? Kernel updates have the potential to completely break things
> (particularly if the security patch comes along with a point release).
Well, admitted the kernel is a special case :-)

Therefore, I wrote "co-maintainers, who should be sufficiently familiar 
with a package" above, and did not write "arbitrary packagers" or 
"arbitrary users". I am presuming "knowledgeable people", who at least 
are able to estimate the impact of a set of changes in cases of "urgent 
security updates".

IMO, arbitrary users' karma are mostly worthless - in general. In most 
cases, all these karma-votes are telling is "update doesn't immediately 
let my system go up in flames".

> I'm not trying to disparage the kernel maintainers, but there's
> absolutely no way they can test all possible hardware before releasing
> an update.
>
> There's still value to the updates-testing repo, even for security
> updates.

Definitely. May-be I wasn't clear enough. I do not want to circumvent 
updates-testing, but wanted to sketch a route to utilize updates-testing 
even for urgent security updates.

> I agree we need to figure out ways to "grease the wheels" so that
> important updates get out faster, though.
The aspect I was referring to is "urgency". In this cases, IMO, it's 
more than appropriate to ask those people who can be assumed to be best 
knowledgeable (e.g. co-maintainers and/or a dedicated "security team") 
to team up.

Of course, this all presumes "critical" packages (firefox, thunderbird, 
kernel, glibc, ssh/ssl etc,) and updates have a team behind and aren't 
soloist efforts.

Ralf