lkml.org 
[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
    From
    Date
    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, <gregkh@linuxfoundation.org>
    >> 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, <
    >>> gregkh@linuxfoundation.org>
    >>>> 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:
    >>>>>
    >>>>> kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.94-rc1.gz
    >>>>> or in the git tree and branch at:
    >>>>> git://
    >>> git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.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
    impossible.

    For reference, the top of tree for both branches is
    v4.14.16-3823-g597d36f1d331
    v4.4.114-12977-ga207b53fe939
    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%).

    Guenter

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