[ubuntu-x] Status of kernel X drivers
eric at anholt.net
Mon Feb 22 16:20:17 UTC 2010
On Sun, 21 Feb 2010 23:20:14 +0000, Ben Hutchings <ben at decadent.org.uk> wrote:
> On Thu, 2010-02-18 at 14:40 -0800, Bryce Harrington wrote:
> > From apw's Kernel Summary, about why we are going with 2.6.32:
> > The primary decision for the kernel team at UDS is to choose the base
> > kernel version for the release. For Lucid this will be 2.6.32. This
> > version has just released providing the maximum stabalisation time, it
> > also is expected to be the kernel of choice for long term releases
> > from other distributions.
> > If other distros are pulling the 2.6.33 drm on top of their 2.6.32 for
> > their long term releases as sounds like is the case, then this would
> > be a fairly significant divergence on our part for no real gain.
> > 2: http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-12/drm-upgrayedd.patch?view=log
> Fedora has been backporting drm (and nouveau) for a long time but it's
> not so clear what means for RHEL.
> I think this is something we will also consider doing in Debian. A year
> from now I expect nv to be dead and radeon UMS to be removed upstream,
> making it impractical to backport new hardware support. Given that, the
> maintenance burden for 2.6.33 drm should be lower. But this is really
> outside my area of expertise and certainly not my decision to make.
> We should probably also consider what this means for drm on the
> 2.6.32-stable branch. Should the drm developers still send patches
> there as well, where applicable? If all the distributions using 2.6.32
> use the backported drm, should we ask Greg K-H to pull that?
Not sure that gregkh would go along with it, but agreed on the other
points, and maybe if distro folks ask for a backport pull instead of
upstream developers we'll have a better chance of success.
The Intel guys should continue sending patches for the current stable
branch. I've seen a bunch of non-Intel folks requesting pulls of
additional drm/i915 patches to stable branches, so hopefully that can
cover 2.6.32 caretaking once our process moves on to the next stable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the kernel-team