Linux Kernel plans for the squeeze cycle
Marc Brockschmidt
As announced on dda [RT1], we want to get an impression when releasing
Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
2009, and some developers have noted that their planned changes wouldn't be
possible in this time frame. So, to find out when releasing would work for
most people, it would be great if you could answer the following questions:
* Which major upstream releases of the linux kernel are expected in the
next two years? Which of those are material for Debian stable, which
might be a bit flaky?
* How many "big" transitions will the upcoming changes cause? When should those
happen? Can we do something to make them easier?
Thanks,
Marc
[RT1] http://lists.debian.org/debian-devel-announce/2009/07/msg00001.html
Ben Hutchings
> Heya,
>
> As announced on dda [RT1], we want to get an impression when releasing
> Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
> 2009, and some developers have noted that their planned changes wouldn't be
> possible in this time frame. So, to find out when releasing would work for
> most people, it would be great if you could answer the following questions:
>
> * Which major upstream releases of the linux kernel are expected in the
> next two years? Which of those are material for Debian stable, which
> might be a bit flaky?
There are no new major versions of the kernel. There is a new "stable"
minor version about every 3 months, which includes all changes that were
considered ready following the last release. Sub-minor versions
("stable updates") fixing critical bugs are released every few weeks for
the current minor version and for some prior minor versions. Long-term
support for any version is left to distributors.
> * How many "big" transitions will the upcoming changes cause? When should those
> happen? Can we do something to make them easier?
Transitions are generally gradual and we can often control them with
build configuration options to enable or disable backward-compatibility
features. Transitions should generally be documented in
Documentation/feature-removal-schedule.txt.
Looking at that now, I see the following potentially disruptive removals
that may occur before squeeze freeze. I have ignored removals that I
know we're ready for.
- Old wireless regulatory domain configuration
- user-space needs to use a new API to specify which country's rules to use; I don't know whether this is in place yet
- Video4Linux API 1
- user-space should use version 2
- b43 support for firmware revision < 410
- maybe we should distribute new firmware
- Ability for non root users to shm_get hugetlb pages based on mlock resource limits
Changes to specific drivers are less well documented and may in some
cases cause real problems at upgrade time.
Ben.
--
Ben Hutchings
Power corrupts. Absolute power is kind of neat.
- John Lehman, Secretary of the US Navy 1981-1987
Ben Hutchings
happened since lenny:
Separation of firmware
This will cause some regressions in hardware support if people do not
install the separate firmware package(s). Users need to be made aware
of this at upgrade time. There is a bug requesting an automated warning
based on driver/hardware detection (#541702).
Removal of OpenVZ, Vserver and Xen packages
These are large and intrusive patches which require significant upstream
effort to adapt to each new kernel version. As a result, they generally
lag availability of new kernel versions and may take much longer to
stabilise, so they can only be frozen some time after the standard
kernel.
There is also no guarantee that the upstream projects will continue to
support the kernel version we release with. For example, official Xen
releases are still based on 2.6.18 with huge changes (though they will
apparently move to a newer version soon). Although we were able to use
SUSE's forward-port of Xen to 2.6.26, SLE 11 was eventually released
with 2.6.27 and so we are on our own with 2.6.26+Xen. Currently, no-one
appears to be ready to maintain these variants in squeeze.
maximilian attems
On Sun, 16 Aug 2009, Ben Hutchings wrote:
> Removal of OpenVZ, Vserver and Xen packages
>
> These are large and intrusive patches which require significant upstream
> effort to adapt to each new kernel version. As a result, they generally
> lag availability of new kernel versions and may take much longer to
> stabilise, so they can only be frozen some time after the standard
> kernel.
openvz dedicated significant ressources to sync with our past Lenny
realease.
as according to a quick glance in their bugzilla we seem to have
gained a significant openvz user base, we might get them again,
maybe?
openvz and also to some extent xen do some upstream merge effort.
> There is also no guarantee that the upstream projects will continue to
> support the kernel version we release with. For example, official Xen
> releases are still based on 2.6.18 with huge changes (though they will
> apparently move to a newer version soon). Although we were able to use
> SUSE's forward-port of Xen to 2.6.26, SLE 11 was eventually released
> with 2.6.27 and so we are on our own with 2.6.26+Xen. Currently, no-one
> appears to be ready to maintain these variants in squeeze.
openvz has had maintenance on the lenny release cycle,
just read changelog as long as upstream is willing to maintain their
2.6.26 tree [1], i'm happy to pass on the fixes.
currently most should be landed in latest Lenny beside one or two
fixes waiting for an ABI change.
[1] http://git.openvz.org/?p=linux-2.6.26-openvz;a=summary
--
To UNSUBSCRIBE, email to debian-rele...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Faidon Liambotis
> Removal of OpenVZ, Vserver and Xen packages
>
> These are large and intrusive patches which require significant upstream
> effort to adapt to each new kernel version. As a result, they generally
> lag availability of new kernel versions and may take much longer to
> stabilise, so they can only be frozen some time after the standard
> kernel.
>
> There is also no guarantee that the upstream projects will continue to
> support the kernel version we release with. For example, official Xen
> releases are still based on 2.6.18 with huge changes (though they will
> apparently move to a newer version soon). Although we were able to use
> SUSE's forward-port of Xen to 2.6.26, SLE 11 was eventually released
> with 2.6.27 and so we are on our own with 2.6.26+Xen. Currently, no-one
> appears to be ready to maintain these variants in squeeze.
merged into mainline and even available into lenny's unpatched kernel
(i.e. the non-xen variant). Could you verify/clarify?
Also, I remember reading about an effort on merging dom0 to mailine.
>From your experience, is there a chance of that happening for 2.6.32?
(the version targetted for squeeze I presume?)
If not, are there any plans of providing a migration path for our users
like e.g. xenner?
(sorry for discussing on -release, but seems applicable)
Regards,
Faidon
Ben Hutchings
> Ben Hutchings wrote:
> > Removal of OpenVZ, Vserver and Xen packages
> >
> > These are large and intrusive patches which require significant upstream
> > effort to adapt to each new kernel version. As a result, they generally
> > lag availability of new kernel versions and may take much longer to
> > stabilise, so they can only be frozen some time after the standard
> > kernel.
> >
> > There is also no guarantee that the upstream projects will continue to
> > support the kernel version we release with. For example, official Xen
> > releases are still based on 2.6.18 with huge changes (though they will
> > apparently move to a newer version soon). Although we were able to use
> > SUSE's forward-port of Xen to 2.6.26, SLE 11 was eventually released
> > with 2.6.27 and so we are on our own with 2.6.26+Xen. Currently, no-one
> > appears to be ready to maintain these variants in squeeze.
> I'm pretty sure that you're referring to Xen *dom0*, since domU is
> merged into mainline and even available into lenny's unpatched kernel
> (i.e. the non-xen variant). Could you verify/clarify?
Correct.
> Also, I remember reading about an effort on merging dom0 to mailine.
> From your experience, is there a chance of that happening for 2.6.32?
I don't think so.
> (the version targetted for squeeze I presume?)
Given a December freeze, that is the likely version.
> If not, are there any plans of providing a migration path for our users
> like e.g. xenner?
I don't know. I don't maintain or use any virtualisation system myself.
maximilian attems
> On Mon, 2009-08-17 at 20:51 +0300, Faidon Liambotis wrote:
> > From your experience, is there a chance of that happening for 2.6.32?
>
> I don't think so.
>
> > (the version targetted for squeeze I presume?)
>
> Given a December freeze, that is the likely version.
>
well,
wouldn't say that this is fixed yet.
last time with keeping linux headers compat to 2.6.25,
we got a freeze exception. so 2.6.33 is a candidate too.
Faidon Liambotis
>> Also, I remember reading about an effort on merging dom0 to mailine.
>> From your experience, is there a chance of that happening for 2.6.32?
>
> I don't think so.
planned for Linux 2.6.32 or 2.6.33 (latest pv_ops dom0 patches can be
found from jeremy's git tree, see instructions below)".
Regards,
Faidon
1: http://wiki.xensource.com/xenwiki/XenParavirtOps
maximilian attems
> Ben Hutchings wrote:
> >> Also, I remember reading about an effort on merging dom0 to mailine.
> >> From your experience, is there a chance of that happening for 2.6.32?
> >
> > I don't think so.
> For the record, Xen upstream[1] mentions "dom0 support, currently
> planned for Linux 2.6.32 or 2.6.33 (latest pv_ops dom0 patches can be
> found from jeremy's git tree, see instructions below)".
>
floating patches are not the maintainance that one expects for
a stable release.
use kvm.
Faidon Liambotis
>>>> Also, I remember reading about an effort on merging dom0 to mailine.
>>>> From your experience, is there a chance of that happening for 2.6.32?
>>> I don't think so.
>> For the record, Xen upstream[1] mentions "dom0 support, currently
>> planned for Linux 2.6.32 or 2.6.33 (latest pv_ops dom0 patches can be
>> found from jeremy's git tree, see instructions below)".
>
> floating patches are not the maintainance that one expects for
> a stable release.
>
> use kvm.
good idea; I merely referred to that quote from upstream for the
"planned for 2.6.32/33" part, which was the point of the discussion, as
quoted above.
Regards,
Faidon