[Devel] patch against 2.6.8.1 (stable)

[Enrico Weigelt]

* Kir Kolyshkin <kir at openvz.org> wrote:

Hi,

> >So, can I assume, the "stable" patch against an quite old kernel 
> >brings the fixes of newer (vanilla) kernels by itself ?
> >  
> As you can see from our changelogs, we have backported a lot of 
> bugfixing stuff from newer kernels, and we are keeping an eye on that.

hmm, I'm sure if its wise to mix up two different jobs - ovz patches
and kernel QM here.

> >I like to keep my kernels as new as possible
> What is your intention? I. e. why you like to keep your kernels as new 
> as possible?

Because I always felt, it is wise to keep it up to date, so bugs
are quickly fixed. Maybe I'm totally wrong, but I worked good with
that all these years.

> >, therefore I did some
> >experiments on porting the "stable" patch to newer versions.
> >  
> The porting itself can bring in different sorts of bugs, so after 
> porting the result can not be considered "stable" anymore.

Yeah, but fetching in some upstream patches may also bring new bugs
and requires much, much works.

> As I tried to explain above, an OpenVZ kernel based on a new 
> mainstream Linux kernel (such as 2.6.16) can not be considered 
> stable just because the new mainstream kernel is not stable 
> enough by itself.

hmm, so you have higher stability requirements for openvz than the 
vanilla kernel has. That's okay, but it sometimes confuses people.

> >hmm, aren't they a job for kernel folks ? or maybe some separate
> >kernel QM project ? (many distros are maintaining their own fixes
> >for the kernel and also dozens of other packages - perhaps try
> >to concentrate these works in one QM project ?)
> >  
> So that is what we do as well, in our stable kernel series. Ours 2.6.8 
> is not just 2.6.8 + openvz patchet; rather it is 2.6.8 + tons of fixes + 
> driver updates + openvz patchset.

hmm, I felt better with it, if these were two things:

a) an fixed kernel with high QM requirements, done by more people
   than just the ovz team
b) the openvz patches, against the QM kernel

The audience for such an QM kernel is probably much, much greater 
than openvz's. So, why not trying to use this potential ?

<snip>

> >As said above: I like to have most recent kernels, as on all my
> >other machines, since I feel its the greatest chance for the best
> >kernel. Maybe I've been wrong all these years.
> >  
> newer kernel != better kernel
> newest kernel != best kernel

:(

Seems to be a common problem. Therefore I'm maintaining patches for
lots of packages, and I've founded an distro-independent QM project.
Maybe you like to have a look at it:

 * http://wiki.metux.de/public/OpenSource_QM_Taskforce
 * http://patches.metux.de/


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------