Lucid Kernel Freeze

Today, March 11th 2010, marks Kernel Freeze for the Lucid kernel.

This means that the kernel moves from active development into its

stabilisation phase. All planned kernel features are now set, included,

and enabled and the kernel team focus now moves from new enablement

to testing, bug isolation, and fixing of issues found in the kernel.

The kernel will now transition over to the stable maintenance team,

they will be responsible for patch acceptance from here on.

What does this transition mean for you. Now is the time to test things you

care about and report any issues in Launchpad against the linux package.

If you have bugs open found earlier in the cycle please retest with the

latest and greatest kernel and report back whether those bugs are still

present and where you tested. The upcoming Beta-1 release is an ideal

test platform.

Additionally this transition means that is will be much harder to make a

change the kernel. From today patches will need to meet the same criteria

as would be required for SRU[1] to a released kernel. That means that

the patch must have a Launchpad bug open, it must be a fix for an actual

bug being experienced in the field, it must be sent to the kernel-team

email list for review, it must recieve two ACKs from kernel team members,

and finally you must test the updated kernels and report back.

Lucid will be with us for a long time so please help us make this the

best kernel possible. Please test beta-1 and report your issues. Thanks!

[1] https://wiki.ubuntu.com/KernelTeam/StableKernelMaintenance

Lucid DRM Update

After much discussion within the Ubuntu Kernel team, the Ubuntu X team,
and with the various Graphics upstreams it has become clear that the
2.6.32 drm stack is not of sufficient quality to form a good basis for a
LTS release.  2.6.32 does not contain Nouveau so we are already committed
to a backport of that for KMS there.  Upstream is essentially saying
ATI Radeon KMS support in 2.6.32 is so bad that the recommendation is to
disable it globally.  Finally i915 does not support the latest chipsets
well, and backports are already extremely painful; chipsets which are
slated to become prevalent over the next few months.

The recommendation from upstream is to use the 2.6.33 drm stack if we
desire KMS to be enabled generally, a clear goal for Lucid.  Following a
review it does appear that the drm subsystem is sufficiently self contained
that it is possible to backport just that subsystem into our 2.6.32 tree.
This gives us a hybrid kernel gaining the long-term stable support backing
for the main kernel (a major bonus as this has to be supported for 5
years on servers) while gaining the more stable 2.6.33 graphics support
for desktop use.  Additionally upstream is essentially rejecting 2.6.32
as a supportable stack, and is committing to longer support for 2.6.33
as their stable version.  We are therefore planning to upload a hybrid
2.6.32 kernel containing the 2.6.33 drm backported.

From an Ubuntu stable maintenance standpoint we should be able to track a
hybrid of 2.6.33.y for drm and 2.6.32.y for the remainder of the kernel and
due to the separation that drm enjoys we hope to avoid major conflicts.
Plug gaining the longest possible support from upstream for each part.
This will also remove the requirement to install an LBM package to get
Nouveau cleaning up the install significantly.  It seems likely that
Debian and other distros will be following a similar hybrid approach
allowing us to share the maintenance burden.