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

[Stefan Bader]

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