Home » Mailing lists » Devel » patch against 2.6.8.1 (stable)
|
|
|
|
|
|
|
|
|
|
| Re: patch against 2.6.8.1 (stable) [message #4328 is a reply to message #4327] |
Wed, 05 July 2006 20:42   |
|
|
Enrico Weigelt wrote:
> * Kirill Korotaev <dev@sw.ru> wrote:
>
>> we have also patches for 2.6.16 on the site and
>>
>
> Is this already stable ? I've just seen the testing patch.
>
1. Stability is not binary thing -- I mean it can be more or less stable.
2. Our stable branch can be thought of as "super stable", and our devel
branch can be thought of as "it works".
3. Devel branch will not be declared stable for at least a few more
months -- just because the kernel it is based on is quite new. New stuff
contains bugs. Old stuff can have those bugs fixed. What we do in our
'stable' series is we backport all the security fixes from the newer
kernels, we also backport essential/relevant bug fixes and some driver
updates as well.
4. In fact, both stable and devel branches are based on the roughly same
code (the only difference is new functionality in devel, like veth
device and checkpointing). So, there are several bug sources/reasons:
- mainstream kernel bugs;
- bugs sneaked in while forward-porting stuff (caused by uncatched
mistakes done while porting);
- bugs in or caused by new features.
While we can bash out last two categories by extensive testing and
bugfixing, bugs from the first category (i.e. mainstream bugs) are
harded to find. They just need some time to be found, and this is mostly
out of our hands.
5. Can you tell us what is your final intention, i.e. what do you need?
We can probably help...
Regards,
Kir.
|
|
|
|
| Re: patch against 2.6.8.1 (stable) [message #4329 is a reply to message #4328] |
Wed, 05 July 2006 23:10 |
Enrico Weigelt
Messages: 31
Registered: July 2006
|
Member |
|
|
* Kir Kolyshkin <kir@openvz.org> wrote:
> Enrico Weigelt wrote:
> > * Kirill Korotaev <dev@sw.ru> wrote:
> >
> >> we have also patches for 2.6.16 on the site and
> >>
> >
> > Is this already stable ? I've just seen the testing patch.
> >
> 1. Stability is not binary thing -- I mean it can be more or less stable.
Yeah, of course. But can it be trusted as stable as the branch
called "stable" ? Is it suited for use in production environments ?
> 2. Our stable branch can be thought of as "super stable", and our devel
> branch can be thought of as "it works".
hmm, so "stable" should better be called "mature" ?
> 3. Devel branch will not be declared stable for at least a few more
> months -- just because the kernel it is based on is quite new. New stuff
> contains bugs. Old stuff can have those bugs fixed. What we do in our
> 'stable' series is we backport all the security fixes from the newer
> kernels, we also backport essential/relevant bug fixes and some driver
> updates as well.
So, can I assume, the "stable" patch against an quite old kernel
brings the fixes of newer (vanilla) kernels by itself ?
I like to keep my kernels as new as possible, therefore I did some
experiments on porting the "stable" patch to newer versions.
> 4. In fact, both stable and devel branches are based on the roughly
> same code (the only difference is new functionality in devel, like veth
> device and checkpointing).
Yeah, these new features may have bugs, and this is the reason for
differentiating between "stable" and "devel" branches :)
I would be happier if I could choose between an these two branches
but both against an new kernel.
> So, there are several bug sources/reasons:
> - mainstream kernel bugs;
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 ?)
<snip>
> 5. Can you tell us what is your final intention, i.e. what do you need?
> We can probably help...
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.
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/
------------------------------------------------------------ ---------
|
|
|
|
| Re: patch against 2.6.8.1 (stable) [message #4336 is a reply to message #4329] |
Thu, 06 July 2006 09:21 |
|
|
Enrico Weigelt wrote:
>> 3. Devel branch will not be declared stable for at least a few more
>> months -- just because the kernel it is based on is quite new. New stuff
>> contains bugs. Old stuff can have those bugs fixed. What we do in our
>> 'stable' series is we backport all the security fixes from the newer
>> kernels, we also backport essential/relevant bug fixes and some driver
>> updates as well.
>>
>
> 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.
> 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?
> , 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.
>> 4. In fact, both stable and devel branches are based on the roughly
>> same code (the only difference is new functionality in devel, like veth
>> device and checkpointing).
>>
>
> Yeah, these new features may have bugs, and this is the reason for
> differentiating between "stable" and "devel" branches :)
>
> I would be happier if I could choose between an these two branches
> but both against an new kernel.
>
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.
>> So, there are several bug sources/reasons:
>> - mainstream kernel bugs;
>>
>
> 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.
>> 5. Can you tell us what is your final intention, i.e. what do you need?
>> We can probably help...
>>
>
> 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
Still, if you want new kernel, I suggest you try our devel kernel. It is
fairly stable; and if it will be not stable enough for you, we will fix it.
|
|
|
|
| Re: patch against 2.6.8.1 (stable) [message #4347 is a reply to message #4336] |
Thu, 06 July 2006 10:59 |
Enrico Weigelt
Messages: 31
Registered: July 2006
|
Member |
|
|
* Kir Kolyshkin <kir@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/
------------------------------------------------------------ ---------
|
|
|
|
Goto Forum:
Current Time: Fri Jul 18 22:31:10 GMT 2025
Total time taken to generate the page: 0.04257 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
