[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel



On Mon, Feb  7, 2011 at 16:28:31 -0500, Michael Gilbert wrote:

> On Mon, 7 Feb 2011 19:12:48 +0100, Moritz Mühlenhoff wrote:
> > Michael Gilbert <michael.s.gilbert@gmail.com> schrieb:
> > > Hi,
> > 
> > > So, my proposal in a nutshell is to only upload upstream 2.6.32 point
> > > releases to wheezy/sid for the next 12-18 months.  At that time,
> > > reevaluate and determine what the next longterm cadence kernel will be,
> > > and then once that is reasonable stabilized in experimental, finally
> > > upload it to unstable for the final stages of wheezy development
> > > (perhaps a few months before the freeze).
> > 
> > No way. The idea of unstable is to get the current upstream code in
> > shape and that won't be achieved with staying with an old kernel.
> 
> I'm not sure if there's a precise definition of unstable other than
> the statement at [0], but it seems to be whatever teams make of it.

unstable is where debian development work happens.

> It's perfectly ok to upload only stable versions (if that's what the
> team wants to do), and its perfectly ok to upload the most unstable
> thing ever, but then the consequences of that have to be dealt with.  I
> guess what I'm saying is that each team can decide specifically how
> they want to use unstable, so the kernel team can deviate from the
> status quo if they decide to; that is if I can make a sufficiently
> convincing argument.
> 
> Also, my suggestion does involve eventually moving to a newer kernel in
> the wheezy development cycle; just a while from now, rather than
> rushing in to things.
> 
What does that buy us?  It means instead of dealing with bugs on an
ongoing basis, you get them all at the same time and get to bisect along
many kernel versions at once instead of just one.  It means problems
don't get reported (and fixed) upstream until it's too late.  It means
any package that could use a newer kernel interface doesn't get any
testing.  I'm sure there's plenty of others.

> > Whatever the technical solution to testing-security kernel might be,
> > it needs to be based on following the upstream kernel development.
> 
> 2.6.32.x is in fact an upstream kernel currently being developed ;)
> 
No it's not.  Go read the definition of development.

I'm sorry, but your proposal is insane.

Cheers,
Julien

Attachment: signature.asc
Description: Digital signature


Reply to: