Integrating 2.6.32.y for lucid
stefan.bader at canonical.com
Mon Nov 16 17:34:10 UTC 2009
Luis R. Rodriguez wrote:
> On Fri, Nov 13, 2009 at 12:04 PM, Tim Gardner <tim.gardner at canonical.com> wrote:
>> Luis R. Rodriguez wrote:
>>> On Fri, Nov 13, 2009 at 5:37 AM, Andy Whitcroft <apw at canonical.com> wrote:
>>>> On Wed, Nov 11, 2009 at 11:30:37AM -0800, Luis R. Rodriguez wrote:
>>>>> Will Lucid also not take the extra version for the uname -r?
>>>>> I had to ask :)
>>>> We are not currently planning on changing the name there no? That is the
>>>> kernel release number, and is in our case the Ubuntu release designation.
>>>> As the stable releases are not merged, but cherry picked often only in
>>>> part it is not clear it is valid to say we are 184.108.40.206 if we are not in
>>>> fact completely so.
>>> You guys are the ones with the experience in cherry picking patches
>>> *out* and *in*, I'm curious would it be possible to move the
>>> discussions that you have internally about these patches themselves
>>> into the linux stable review list instead?
>>> I don't think other distributions do this but I don't particularly
>>> care about what others do, I'm trying to understand if something like
>>> this *is* possible or not.
>>> In other words it would seem to me your own careful analysis of stable
>>> patches would be kindly welcomed for the stable releases and seriously
>> AFAIK Stefan is already involved in the upstream stable review process.
>> We generally take a second look at the stable updates in case some of
>> them don't make sense from a distro perspective.
> Understood -- I'm just wondering if the arguments to drop a patch
> might be useful for stable upstream discussion as well.
I think I will going to give a bit more feedback there. I often have/had the
problem of the deadline and receiving the review mail clashed a bit with working
hours, so I felt the feedback would have come too late anyways. I have been asking
whether potentially this could be a bit prolongued (especially as going over a hundred
patches takes a bit of time, not that its always that much).
More information about the kernel-team