Re: Sarge kernels and Volatile
On Tue, Aug 02, 2005 at 06:10:38PM -0400, Michael Stone wrote:
> On Tue, Aug 02, 2005 at 03:43:42PM -0400, Andres Salomon wrote:
> >until fairly recently; we've gotten conflicting answers ranging from "We
> >should provide kernel updates and the security team will use them
> generally the security team at least glances at what's released in a
> >to "Don't even bother providing an update, you're just wasting
> >your time".
> I have no idea who said that.
> >problems and build (and work) on all 11 archs. We need to know just how
> >much leeway we have with our update; can we include an ABINAME bump?
> We've done it before when absolutely necessary. I'd expect that to be a
> last resort, because it'll definately screw people who expect apt-get to
> magically upgrade them.
> >Can we include other important fixes?
> Not in a security update, unless it's security-critical. You can argue
> with the stable release manager over additional changes to a package in
> >of security fixes that don't break the ABI? Will you leave it up to our
> >judgement as to what security fixes to include, or will you have to ok
> >each and every patch?
> Expect it to be reviewed, but as long as you don't make any mistakes
> your judgement should be fine. :)
> >As for taking responsibility for the security updates, I believe Horms
> >is more than willing
> He's the one who told me nobody was coordinating kernel security
I ment from the security-team side. Which is what I thought you were
asking. Sorry that I misunderstood your question. I forgot you
are part of the security team.
On the kernel team side, I am more than happy to coordinate security
updates, at least for the time being. But as Andres mentioned, there
isn't much point in going through this pain unless there is a good
chance the security team is going to accept the changes. From your posts
here I'd say that there is a good chance and that it is worth our while
to produce security updates. This pleases me immensely, thanks.
Moving forward there are a few issues.
* You've already stated that only security up dates are acceptable.
Thanks for that clarification. It does however mean we will probably
have to stick with our volatile packages plan as well.
* ABI bump seems unmanageable to me. However we do have a security
bug that requires and ABI bump. The bug in question is CAN-2005-0449
Is this considered to be absolutely necessary? I'd say no.
* All 11 arches is difficult. For historical reasons the kernel
in Sarge is divided up into a source package and then per-arch image
packages. What this means is that the source is prepared, and then
the per-arch images are prepared. The whole cycle involves quite a
number of people and typically takes at least two weeks.
Yes, we know this process is broken, and we are working hard to fix
it for Etch, but thats the way it is. Is it a hard requirement
that all 11 arches be ready at the same time? The reality
is that the kernel's aren't actually completely in sync in Sarge,
so it would seem that security updates might not need to be either.
* As for review. Building these packages takes ages. Is it possible
for the security team to at least review the change log to
accept and reject changes early on?