RFC: Stable kernel updates and the SRU process

[Ben Collins]

Stefan Bader wrote:
> Ben Collins wrote:
>> Stefan Bader wrote:
>>> Tim Gardner wrote:
>>>> I would like to propose the following change in policy with regard to
>>>> the Ubuntu kernel and stable tree updates.
>>>>
>>>> In the past our kernels have incorporated stable kernel tree updates up
>>>> to the point of kernel freeze. After that point, only those patches that
>>>> were specifically referenced by SRU Launchpad reports were applied.
>>>>
>>>> The upstream process for stable tree updates is quite similar in scope
>>>> to the SRU process, e.g., each patch has to demonstrably fix a bug, and
>>>> each patch is vetted by upstream by originating either directly from
>>>> Linus' tree or in a minimally backported form of that patch.
>>>>
>>>> I think we are remiss if we do not take advantage of that upstream
>>>> process to improve our kernel. Therefore I propose that we modify our
>>>> kernel update policy such that we adopt stable kernel updates at
>>>> appropriate points in the release process (avoiding kernel freezes etc)
>>>> for as long as upstream continues to provide updates, and that these
>>>> stable kernel updates not be subject to the SRU process.
>>>>
>>>> Comments?
>>>>
>>>> rtg
>>> I would also be in favor of such a change. In the past there have been
>>> several
>>> bug that were fixed by changes in the stable tree which we had to
>>> search for
>>> and then pull in. Also the patches in the stable tree are generally
>>> small and
>>> it takes a review process to get them in. So why not simplify our
>>> workload by
>>> pulling them in by default. I'd also only do one tracking bug per
>>> stable release.
>>>
>> I should point out that regardless of the upstream process, we have, in
>> the past, gotten regressions due to these changes.
>>
>> Hence the reason we have the current policy.
> 
> Still I think it would be better to revert selectively if there are regressions
> found than only to select a few patches and miss fixes until we get bitten by them.

Then I think this should be accompanied by an extended bit of time in 
-proposed when such a blanket merge is done with the .y tree.