[RFC] Process for maintaining stable updates for drm for Lucid

Mon Aug 30 17:08:08 UTC 2010

One thing that I would like to point out is that, there are some 
infrastructural changes that have gone into drm since 2.6.33. Many/Most of 
the recent patches reference that new infrastructure. OEMs prefers to 
base on lucid, and they have products that are scheduled to be released 
based on newer intel chipsets. The patches that go into upstream for these 
chipsets will need to be backported from .35 to lucid, and also any 
reference to new infrastructure changed to use the old one. I am concerned 
this might lead to other problems. My suggestion if a patch has a 
dependency, we should try to pull in the dependency as well instead of 
backporting to .32.

Cheers
--- manjo

On Mon, 30 Aug 2010, Stefan Bader wrote:

> On 08/30/2010 02:27 AM, Ben Hutchings wrote:
>> On Sun, 2010-08-29 at 16:26 -0700, Brad Figg wrote:
>>> On 08/29/2010 02:17 PM, Ben Hutchings wrote:
>>>> On Thu, Aug 26, 2010 at 10:04:16AM -0500, Steve Conklin wrote:
>>>>> The Lucid kernel consists of the 2.6.32 kernel plus the DRM tree from
>>>>> 2.6.33. Now that GregKH has announced the end of stable updates for the
>>>>> 2.6.33 kernel, the Ubuntu kernel stable maintenance team has been
>>>>> discussing the best way to continue to maintain a set of stable updates
>>>>> for the 2.6.33 DRM.
>>>>>
>>>>> I have prepared a wiki page based on our discussions, and would now like
>>>>> to open discussion to the Ubuntu kernel team mailing list.
>>>>
>>>> I'm interested in cooperating in this.
>>>>
>>>> I have prepared a git branch with drm changes from 2.6.34.3 up to
>>>> 2.6.34.6 as a basis for Debian kernel updates.  I can make that
>>>> public and post the patches for review if you want to consider
>>>> pulling that.
>>>>
>>>> Ben.
>>>>
>>>>
>>>
>>> Ben,
>>>
>>> What are your thoughts on taking drm patches once the 2.6.34 stable tree
>>> closes?
>>
>> I think we should keep taking applicable patches from the oldest active
>> stable series after 2.6.33, possibly adding intermediate patches that
>> they depend on (example: da7be68, backported to 2.6.34.6, depends on
>> c414a11, not present in 2.6.33.y).
>>
>> The Debian kernel update policy is:
>> <http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines>.
>>
>> Ben.
>>
>>
>
> We surely are interested in looking through 2.6.34.y drm patches to see which
> ones we think look good. If you already got a tree prepared there, lets have a
> look together. Our policies for patches are close there and also close to what
> upstream stable has. While 2.6.33.y existed we chose to require people to submit
> it to upstream stable as this ensured at least that subsystem maintainers would
> be involved in the review and could intervene if things would not be applicable.
> And sending patches to upstream stable also ensures fixes would go upstream (if
> still being applicable).
> So the big question is how we go forward now that .33 and .34 have gone out of
> support upstream? Some thoughts I have here are:
>
> - patches need to be tested to fix the reported issues
> - we should prefer patches from upstream
>  - if backports are required or the patch only is relevant to .33, we should
>    require/ask for an ack from a subsystem maintainer.
> - we probably should require (as upstream stable does) that patches are self
>  contained and small. Otherwise someone will come up with a giant backport
>  just because it fixes and issue.
> - maybe some sort of review mechanism like Greg does would be useful
>
> We had been talking about the idea of looking at upstream stable patches for drm
> in general. Though our feeling was that the more into the future we go, the less
> applicable are patches there in general. And even if they apply, they might
> depend on changes not present and thus break things. So we basically need a way
> to proceed in a manner that allows us to get fixes while trying to keep
> regressions out. Ideally we would have subsystem maintainers support by having
> them add comments about .33 compliance when submitting to upstream stable. But I
> guess that is too much to ask for.
>
> I think we (Debian and Ubuntu) can gain a lot from working together on this. And
> Ben, feel free to bring up anything that you think won't work for Debian or
> things you think would be better. We basically want to have an upstream stable
> LTS for drm in .33 while not having the benefit of having the same upstream
> support as Greg does (maybe yet).
>
> Stefan
>
>
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
>