Stable Release policy?

Stable Release policy?

[Nicholas Lee]

What is the stable release policy going to be is there is a securty
hole that a later (than current) kernel fixes?

For instance 2.0.5 has 2.6.10, whereas both 2.6.11.2 and 2.6.11 have
mentions of security related patches.

Nicholas

RE: Stable Release policy?

[Ian Pratt]

> What is the stable release policy going to be is there is a securty
> hole that a later (than current) kernel fixes?
> 
> For instance 2.0.5 has 2.6.10, whereas both 2.6.11.2 and 2.6.11 have
> mentions of security related patches.

You'll find that the vast majority of Linux security patches will apply
cleanly to one of our arch-xen kernels. 

Now that mainstream Linux has moved over to a point release scheme I
guess we could modify our build procedure to go looking to see whether
there are updates available. 
It'll just be a pain on the very rare ocasions where this breaks the
build.

It's really an issue for whoever is doing the packaging. In the
not-so-long-term, this will hopefully be an issue for the vendor of your
favourite distribution rather than us.

Ian

Re: Stable Release policy?

[Mark Williamson]

> > What is the stable release policy going to be is there is a securty
> > hole that a later (than current) kernel fixes?
> >
> > For instance 2.0.5 has 2.6.10, whereas both 2.6.11.2 and 2.6.11 have
> > mentions of security related patches.
>
> You'll find that the vast majority of Linux security patches will apply
> cleanly to one of our arch-xen kernels.

From what I've seen of the new stable patches, they rarely modify 
arch-dependent code.

Have you tried just applying them?  The only problematic changes are ones 
under arch/i386.

Cheers,
Mark

> Now that mainstream Linux has moved over to a point release scheme I
> guess we could modify our build procedure to go looking to see whether
> there are updates available.
> It'll just be a pain on the very rare ocasions where this breaks the
> build.
>
> It's really an issue for whoever is doing the packaging. In the
> not-so-long-term, this will hopefully be an issue for the vendor of your
> favourite distribution rather than us.
>
> Ian
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

RE: Stable Release policy?

[Rik van Riel]

On Tue, 29 Mar 2005, Ian Pratt wrote:

> It's really an issue for whoever is doing the packaging. In the
> not-so-long-term, this will hopefully be an issue for the vendor of
> your favourite distribution rather than us.

Absolutely.  This isn't something an upstream project should
spend too much time on, IMHO.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Stable Release policy?

[Nicholas Lee]

On Tue, 29 Mar 2005 22:33:11 +0100, Mark Williamson
<mark.williamson@cl.cam.ac.uk> wrote:
> Have you tried just applying them?  The only problematic changes are ones
> under arch/i386.

[nic@stateless:/usr/src/linux-2.6.11.6] patch -p1 -s  <
../xen/xen-2.0.bk/patch-2.6.10-xen0
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
3 out of 3 hunks ignored -- saving rejects to file include/linux/skbuff.h.rej
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej

>From the looks of include/linux/skbuff.h it should be fine to ignore
skbuff.h.rej.

I assume that everything else should be fine.

Nicholas

Re: Stable Release policy?

[Mark Williamson]

> [nic@stateless:/usr/src/linux-2.6.11.6] patch -p1 -s  <
> ../xen/xen-2.0.bk/patch-2.6.10-xen0
> Reversed (or previously applied) patch detected!  Assume -R? [n]
> Apply anyway? [n]
> 3 out of 3 hunks ignored -- saving rejects to file
> include/linux/skbuff.h.rej 1 out of 1 hunk FAILED -- saving rejects to file
> Makefile.rej
>
> >From the looks of include/linux/skbuff.h it should be fine to ignore
>
> skbuff.h.rej.

This may be because one of the Xen support patches has been intergrated into 
the mainline (anyone know if this is the case?).  If so, then it's fine.

> I assume that everything else should be fine.

FYI, the 2.6.11.6 patch applies fine to 2.6.11-xen0 in the 2.0-testing tree 
(ie. the only reject is on the top level makefile).

Cheers,
Mark

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Stable Release policy?

[Nicholas Lee]

On Apr 1, 2005 1:14 AM, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:
> FYI, the 2.6.11.6 patch applies fine to 2.6.11-xen0 in the 2.0-testing tree
> (ie. the only reject is on the top level makefile).

How stable is -testing at the moment?  Had some compile issues with my
patch. Which I haven't had a chance to track down.

Nicholas

RE: Stable Release policy?

[Ian Pratt]

 

> On Apr 1, 2005 1:14 AM, Mark Williamson 
> <mark.williamson@cl.cam.ac.uk> wrote:
> > FYI, the 2.6.11.6 patch applies fine to 2.6.11-xen0 in the 
> 2.0-testing 
> > tree (ie. the only reject is on the top level makefile).
> 
> How stable is -testing at the moment?  Had some compile 
> issues with my patch. Which I haven't had a chance to track down.

-testing is generally very stable since it's mainly bug fixes to the
previous release, plus certain new features that look 'safe'.

Having said that, it went through a wobble yesterday while the correct
fix to the blk device performance problem was being found, but that was
the first time in ages.

Ian