We have been producing the mainline kernel crack of the day[1] for some time now. But this targets the upstream kernel, and while great for testing and bug isolation it does not provide us with any pre-upload testing on the Ubuntu kernel delta.
Enter the pre-proposed kernel PPA[2]. We are now uploading the unreleased tips of the ubuntu kernel trees to this PPA. These builds will contain any bug fixes marked Fix Committed and should provide a vehicle for advanced testing of these before they hit the archive. For Maverick we will be uploading these automatically as the tree changes, roughly daily. This should help us avoid the ThinkPad debackle we experienced late in Lucid.
I would encourage you to add this PPA to your sources and help us test this kernel before we unleash it on the world.
[1] https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
[2] https://edge.launchpad.net/~kernel-ppa/+archive/pre-proposed/
Friday, 2 July 2010
Tuesday, 1 June 2010
Union Filesystem Plans
At UDS we return to the subject of those drivers we are carrying which are specific to Ubuntu, why they are not yet upstream and what we can do about it. Union Filesystems are a key technology in producing the live CD environment used to allow both non-destructive testing and the graphical installer. This technology has long been a contentious subject as the patch sets have been extensive and intrusive to the VFS. Worse there have been a number of camps all disagreeing as to the most sensible solution.
For a number of series we have carried the AUFS/AUFS2 patch kit as an Ubuntu add on. This has been a solid performer in this space and served our purposes well. About a year ago now talk began upstream on what approach would be acceptable to upstream. This has resulted in a proposed for an integrated VFS based solution for union filesystems called union-mounts. Patches have been circulating for the best part of a year and we skirted with them for the Lucid cycle, at that time they were feature incomplete preventing full testing.
Recently updated patches have been circulated which should be feature complete, and we are planning to provide kernels enabled for union-mount for testing in a PPA. Should testing there prove good we will consider switching to this solution for our live CDs. Watch this space as they say.
For a number of series we have carried the AUFS/AUFS2 patch kit as an Ubuntu add on. This has been a solid performer in this space and served our purposes well. About a year ago now talk began upstream on what approach would be acceptable to upstream. This has resulted in a proposed for an integrated VFS based solution for union filesystems called union-mounts. Patches have been circulating for the best part of a year and we skirted with them for the Lucid cycle, at that time they were feature incomplete preventing full testing.
Recently updated patches have been circulated which should be feature complete, and we are planning to provide kernels enabled for union-mount for testing in a PPA. Should testing there prove good we will consider switching to this solution for our live CDs. Watch this space as they say.
Sunday, 16 May 2010
Maverick UDS: the hangover
What a mad week. Finally UDS is over and at least some of us are back home, dispite the efforts of a certain Icelandic volcano and of Eurostar. For me this has been one of the most valuable I have attended. I suspect in large part this is due to my being more experienced in the 'one hour to rule the world' mentality. The rather fetching five minute warning popups were pretty handy to focus the mind on getting the pertinent actions into the gobby seance.
Last cycle I was Kernel Release Manager, this meant that I had responsibility for all of the core kernel blueprints and meant I was tied to the kernel track almost exclusively. With that responsibility passing to Leann I found myself free to rove to other tracks and stick my nose in. I attended a number of X/graphics related discussions. It was great to meet those behind the IRC nicks which I deal with so very often.
More on what we are going to be playing with once the hangover dissipates, in the meantime some Guitar Hero me thinks.
Friday, 23 April 2010
Lucid Kernel Final Configuration
Now that release is fast approaching it was thought appropriate to advertise the final kernel configurations for all of the main distro and ports kernel flavours. The purpose is to expose the main configuration changes to scrutiny and to provide pointers to the full configurations where those are of interest.
For Lucid we have aimed primarily on stabilisation and supportability. As such we do not expect there to be any radical configuration changes in these kernels. There has been a drive to commonise and standardise options between architectures and flavours where at all possible to help standardise the experience. There has also been a drive to pull out to modules some sub-systems which are commonly replaced by users, such as HID, and also pulling out the majority of the PATA and SATA drivers as it is most common to only require a single one of these. We have also enabled KMS for all graphics hardware where it is supported.
To aid in this comparison we have generated a delta report between Karmic and Lucid which shows all items which have changed and how the value has changed. This report can be found at the URL below:
https://wiki.ubuntu.com/KernelTeam/Configs/KarmicToLucid
To facilitate series to series comparison we include pointers to both the full Karmic and Lucid configurations for each flavour, all of which can be found at the URL below:
http://kernel.ubuntu.com/~kernel-ppa/configs/
For Lucid we have aimed primarily on stabilisation and supportability. As such we do not expect there to be any radical configuration changes in these kernels. There has been a drive to commonise and standardise options between architectures and flavours where at all possible to help standardise the experience. There has also been a drive to pull out to modules some sub-systems which are commonly replaced by users, such as HID, and also pulling out the majority of the PATA and SATA drivers as it is most common to only require a single one of these. We have also enabled KMS for all graphics hardware where it is supported.
To aid in this comparison we have generated a delta report between Karmic and Lucid which shows all items which have changed and how the value has changed. This report can be found at the URL below:
https://wiki.ubuntu.com/KernelTeam/Configs/KarmicToLucid
To facilitate series to series comparison we include pointers to both the full Karmic and Lucid configurations for each flavour, all of which can be found at the URL below:
http://kernel.ubuntu.com/~kernel-ppa/configs/
Enjoy!
Thursday, 11 March 2010
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
Friday, 5 March 2010
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.
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.
Subscribe to:
Posts (Atom)