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.
thanks,
greg k-h
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
On Tue, Feb 06, 2018 at 06:48:17AM -0800, Guenter Roeck wrote:
On 02/06/2018 05:14 AM, Greg Kroah-Hartman wrote:
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
Ugh, 12k patches is not trivial, gotta love those graphic drivers :(
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%).
Thanks a lot for the feedback, this helps out a lot when talking to companies that are "afraid" of doing merges with stable.
Based on this, one phone vendor just forward merged their 4.4.y based tree to the latest release in a few hours with no reported problems at all, so it has already helped out with tangable results.
thanks,
greg k-h
On Wed, Feb 07, 2018 at 06:37:06AM -0800, Greg Kroah-Hartman wrote:
On Tue, Feb 06, 2018 at 06:48:17AM -0800, Guenter Roeck wrote:
On 02/06/2018 05:14 AM, Greg Kroah-Hartman wrote:
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
Ugh, 12k patches is not trivial, gotta love those graphic drivers :(
That, plus a gazillion backports, plus vendor specific out-of-tree wireless drivers, plus all the Android stuff. No, there is no "love" involved, only annoyance :-(.
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%).
Thanks a lot for the feedback, this helps out a lot when talking to companies that are "afraid" of doing merges with stable.
Based on this, one phone vendor just forward merged their 4.4.y based tree to the latest release in a few hours with no reported problems at all, so it has already helped out with tangable results.
Excellent. More test coverage!
Guenter
linux-stable-mirror@lists.linaro.org