Tested your Lucid sru-18+19 branch

Stefan Bader stefan.bader at canonical.com
Mon Aug 23 14:44:17 UTC 2010


On 08/23/2010 04:32 PM, Brad Figg wrote:
> On 08/23/2010 07:16 AM, Stefan Bader wrote:
>> On 08/23/2010 04:02 PM, Brad Figg wrote:
>>> On 08/23/2010 01:14 AM, Stefan Bader wrote:
>>>> On 08/21/2010 04:03 PM, Brad Figg wrote:
>>>>> On 08/20/2010 01:38 PM, Tim Gardner wrote:
>>>>>> Looks good. The desktop responsiveness is far superior under load compared to what it was at release.
>>>>>>
>>>>>> rtg
>>>>>
>>>>> Greg released .20 on Friday. In it were two mm patches. We already carry both
>>>>> of these patches so we are already up-to-date with respect to .20.
>>>>>
>>>>> Brad
>>>>
>>>> Right, I would propose a 2.6.32.19/20 update (the tracking bug) in this case.
>>>> For us the update between .19 and .20 is no change.
>>>>
>>>> Stefan
>>>>
>>>
>>> The tracking bug is setup as a 18/19/20 tracking bug.
>>>
>>> Brad
>>
>> I think I noted somewhere before that I would at least split up 18 and 19. Those
>> releases are big enough to be better tracked in their own report.
>>
>> Stefan
>>
> 
> I don't have a problem splitting the application of the patches
> into two pull requests however I don't understand why you want
> it done. There is no ABI bump in the entire set and .20 is a
> no-op. There are only 32 commits between .17 and .18.
> 
> Brad

Mainly for regression reporting and maybe a bit for more fine grained tasks.
It also makes it a bit more obvious from the buglink which of the stable updates
the patch originated from.

So yes, .20 is a no-op. For that I agree .19+.20 as one bug makes sense. Though
for.18 (even being only 32) I think it make sense to have a separate tracking
and bug number.

Stefan




More information about the kernel-team mailing list