Re: [vserver] Stable Linux-VServer Release

On Fri, 29 Jul 2011 21:19:44 +0200Herbert Poetzl <herbert@13thfloor.at> wrote:

> On Thu, Jul 28, 2011 at 03:36:10PM +0200, Herbert Poetzl wrote:
>
> > There have been numerous 'requests' for a new Stable
> > release and it seems like the Linux-VServer community
> > is willing to 'sponsor' the stabilization process ...
>
> [zapped]
>
> > thus the first thing is to select a kernel we want
> > to stabilize for a stable release ...
>
> > options IMHO are:
>
> > - 2.6.32.x (has performance issues, but is long term)
> > - 2.6.38.x (good performance, not longterm yet)
> > - 3.0.x (immature, but the future)
>
> here the status so far:
> all the money so far is on 2.6.32.x while the majority
> votes for 3.0.x ...
>
> 2.6.32.x 2.6.38.x 3.0.x Other $$$
> -----------------------------------------------------------------
> Tor Rune Skoglund - - X -
> Gordan Bobic - X X -
> John A. Sullivan III - - X -
> Roman Vesely X - - - 500 USD
> Nikolay Kichukov X - - -
> Michael Auckland - - X -
> Mr Jarry - - - X
> Corey Wright X - - -

Corey Wright - - - X 100 USD

> Sandino Araico Sánchez X - - - 200 USD
> Romain Riviere - X X -
>
> please correct me if I did misinterpret any response ...

my apologies for misleading anybody with my commentary on 2.6.32 vs 2.6.35. i
was merely trying to explain why 2.6.35 wouldn't be considered (especially in
light of 2.6.32).

my personal preference is the first 3.x to go longterm because, as ed,
benedikt, and i believe others have said...

i've already had to move beyond 2.6.32 for hardware support. i'm a
"hobbyist", but even if i was using 2.6.32 "professionally", i'm not sure i
would want the project to start stabilizing against a kernel already 1.5
years old. yes, redhat will continue to support it for years with rhel6 (and
centos and scientific), but redhat will also be backporting hardware drivers
and features while the linux-vserver patch will only be against a pristine
kernel.org version (unless specifically funded or contributed). instead of
what people are currently using, we should be asking ourselves, "what will be
the lifespan of this stable patch and what kernel version is best for that
time-frame?" if people say "1 to 2 years", then will 2.6.32.z still be
practical (on new hardware) or relevant (without newer features; eg cgroup
blkio) a year from now? and that's not a rhetorical question hinting that it
won't be; i don't know.

i'm currently using 2.6.35, but that hasn't been spoken of as an option. i
don't disagree with it not being considered for the linux-vserver project
at-large and the current 2.6.35.13-vs2.3.0.36.33 patch works fine for my
current use-case.

2.6.38 is not currently longterm and i don't expect that it will as nobody
has spoken up yet and stable support expired nearly 2 months ago.

this leaves 3.x, which i figure will be the next longterm kernel (though
maybe 2.6.39). note i'm not saying 3.0.y, because i don't know that anybody
will pick up 3.0 for longterm. it'll receive stable support, but how far
will that take it and do we care that after ~6 months our targeted kernel has
no upstream support? in a week or two i intend to test the 3.0 kernel with
the latest vserver patch on debian squeeze (my preferred vserver host distro)
to test the viability of using a stable vserver patch against 3.x with
squeeze, though i'm pretty sure i'll have to use a backported kernel-package
and possibly initramfs-tools, etc.

and i'm pitching in $100 USD, not for stabilizing any specific kernel version
(though i've voiced my opinion above and would like to see ipv6 support match
ipv4), but to support future linux-vserver and util-vserver development in
general. (herbert, just tell me how to get it to you from the usa.)

corey

--
undefined@pobox.com
> best,
> Herbert
> 
> > note that whatever kernel we choose, the stabilization
> > will be for that kernel only, i.e. there is no way to
> > port such a kernel to the other branch (without need
> > to redo all the testing and review)
> 
> > please share your thoughts and preferences in this
> > thread so that we get an idea where we are heading to
> 
> > thanks in advance,
> > Herbert