[lkml]   [2018]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 3.18 00/36] 3.18.94-stable review
On 02/06/2018 05:14 AM, Greg Kroah-Hartman wrote:
> On Tue, Feb 06, 2018 at 11:42:15AM +0000, Harsh Shandilya wrote:
>> On Tue 6 Feb, 2018, 4:04 PM Greg Kroah-Hartman, <>
>> wrote:
>>> On Tue, Feb 06, 2018 at 06:48:53AM +0000, Harsh Shandilya wrote:
>>>> On Tue 6 Feb, 2018, 12:09 AM Greg Kroah-Hartman, <
>>>> wrote:
>>>>> This is the start of the stable review cycle for the 3.18.94 release.
>>>>> There are 36 patches in this series, all will be posted as a response
>>>>> to this one. If anyone has any issues with these being applied, please
>>>>> let me know.
>>>>> Responses should be made by Wed Feb 7 18:23:41 UTC 2018.
>>>>> Anything received after that time might be too late.
>>>>> The whole patch series can be found in one patch at:
>>>>> or in the git tree and branch at:
>>>>> git://
>>>>> linux-3.18.y
>>>>> and the diffstat can be found below.
>>>>> thanks,
>>>>> greg k-h
>>>> Builds and boots on the OnePlus 3T, no regressions noticed.
>>> Yeah! That device is the only reason I keep this tree alive :)
>>> thanks for testing and letting me know.
>>> greg k-h
>> Guess I should drop my kernel tree for the device and save you the pain of
>> maintaining 3.18 :P
> Heh, maybe :)
>> Atleast CAF has been keeping up with upstream now thanks to your
>> kernel-common merges so there's still hope for MSM platform users :)
> That's good to see. Now if only those platform users would actually
> update their kernels to these new versions :(
>> P.S. common merge should go in cleanly, both the merge conflicts I had were
>> from CAF changes.
> Thanks for letting me know, that's great to hear as I just had a
> question from some companies who are worried that taking stable patches
> will cause tons of merge issues. It hasn't in my experience, and seeing
> reports of this from others is great news.

From merging v4.4 and v4.14 into the respective ChromeOS branches, I would conclude
that merging is for the most part easy. Major source of conflicts, if they happen,
is that we may already have picked up additional commits from upstream.

This is only true, though, if merges are done on a release-by-release basis
and if the merge happens shortly after a stable release is available. Otherwise,
as time goes by, merges become more and more difficult (almost exponentially
over time). Wait for more than 2-3 months between merges and it becomes almost

For reference, the top of tree for both branches is
meaning there are _lots_ of patches on top of the mainline stable releases.

Also, overall, the rate of regressions is quite low (if I recall correctly,
somewhere between 3 and 5 in chromeos-4.4, and one so far in chromeos-4.14,
ie below 0.1%).


 \ /
  Last update: 2018-02-06 15:49    [W:0.067 / U:6.848 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site