Hi Greg,
please pull commit 71546d100422b ("percpu: include linux/sched.h for cond_resched()") into v4.14.y to avoid build errors for microblaze and other architectures.
Also, with that many patches queued, can we possibly get more than the usual number of days for testing the next round of stable releases ?
Thanks, Guenter
On Wed, May 02, 2018 at 11:28:21PM -0700, Guenter Roeck wrote:
Hi Greg,
please pull commit 71546d100422b ("percpu: include linux/sched.h for cond_resched()") into v4.14.y to avoid build errors for microblaze and other architectures.
Thanks, I'll do that, there's a bunch of build failures and warnings right now to fix up. For most I'm just going to drop patches.
Also, with that many patches queued, can we possibly get more than the usual number of days for testing the next round of stable releases ?
Oh yes, this is going to be a rough one :)
thanks,
greg k-h
On 05/03/2018 04:53 AM, Greg Kroah-Hartman wrote:
On Wed, May 02, 2018 at 11:28:21PM -0700, Guenter Roeck wrote:
Hi Greg,
please pull commit 71546d100422b ("percpu: include linux/sched.h for cond_resched()") into v4.14.y to avoid build errors for microblaze and other architectures.
Thanks, I'll do that, there's a bunch of build failures and warnings right now to fix up. For most I'm just going to drop patches.
Sounds good. Note that 3.18.y needs the patch as well.
Also, with that many patches queued, can we possibly get more than the usual number of days for testing the next round of stable releases ?
Oh yes, this is going to be a rough one :)
Yes, this one looks really bad. Not only build failures, but various architectures which do build fine don't even boot (including x86). You might want to have a look into my build system to get an idea, though I expect that 0day will keep you busy for a while. Let me know when you need specific feedback and/or help with specific problems.
Thanks, Guenter
On Thu, May 03, 2018 at 06:36:35AM -0700, Guenter Roeck wrote:
On 05/03/2018 04:53 AM, Greg Kroah-Hartman wrote:
On Wed, May 02, 2018 at 11:28:21PM -0700, Guenter Roeck wrote:
Hi Greg,
please pull commit 71546d100422b ("percpu: include linux/sched.h for cond_resched()") into v4.14.y to avoid build errors for microblaze and other architectures.
Thanks, I'll do that, there's a bunch of build failures and warnings right now to fix up. For most I'm just going to drop patches.
Sounds good. Note that 3.18.y needs the patch as well.
It does? Ok, I'll add it there.
Also, with that many patches queued, can we possibly get more than the usual number of days for testing the next round of stable releases ?
Oh yes, this is going to be a rough one :)
Yes, this one looks really bad. Not only build failures, but various architectures which do build fine don't even boot (including x86). You might want to have a look into my build system to get an idea, though I expect that 0day will keep you busy for a while. Let me know when you need specific feedback and/or help with specific problems.
Thanks, I think the new requirement for taking Sasha's patches is that they at least pass 0-day first before sending them to me...
thanks,
greg k-h
On Thu, May 03, 2018 at 08:28:37AM -0700, Greg Kroah-Hartman wrote:
On Thu, May 03, 2018 at 06:36:35AM -0700, Guenter Roeck wrote:
On 05/03/2018 04:53 AM, Greg Kroah-Hartman wrote:
On Wed, May 02, 2018 at 11:28:21PM -0700, Guenter Roeck wrote:
Hi Greg,
please pull commit 71546d100422b ("percpu: include linux/sched.h for cond_resched()") into v4.14.y to avoid build errors for microblaze and other architectures.
Thanks, I'll do that, there's a bunch of build failures and warnings right now to fix up. For most I'm just going to drop patches.
Sounds good. Note that 3.18.y needs the patch as well.
It does? Ok, I'll add it there.
Ah, I see what I did wrong to not notice it. Now added, thanks.
greg k-h
On Thu, May 03, 2018 at 08:28:37AM -0700, Greg Kroah-Hartman wrote:
Oh yes, this is going to be a rough one :)
Yes, this one looks really bad. Not only build failures, but various architectures which do build fine don't even boot (including x86). You might want to have a look into my build system to get an idea, though I expect that 0day will keep you busy for a while. Let me know when you need specific feedback and/or help with specific problems.
Thanks, I think the new requirement for taking Sasha's patches is that they at least pass 0-day first before sending them to me...
As I just mentioned in the other thread, I think this is going a bit too far. Browsing through the patches, many of them don't have a stable or Fixes: tag, but just mention "fix" somewhere. It almost looks like many are being applied shotgun-wise, without real idea if the problem solved really applies to the target release.
It is quite likely that the upcoming stable release will cause a lot of regressions. This in turn may jeopardize my last two years of work trying to convince the rest of the ChromeOS team to see the benefits of stable release merges. It may put our entire stable release merge strategy at risk.
I really would prefer a more conservative approach for stable releases.
[ And all that while trying to limit the ability to push bug fixes into mainline. Weird. Makes my head spin. ]
Thanks, Guenter
On Thu, May 03, 2018 at 08:57:30AM -0700, Guenter Roeck wrote:
On Thu, May 03, 2018 at 08:28:37AM -0700, Greg Kroah-Hartman wrote:
Oh yes, this is going to be a rough one :)
Yes, this one looks really bad. Not only build failures, but various architectures which do build fine don't even boot (including x86). You might want to have a look into my build system to get an idea, though I expect that 0day will keep you busy for a while. Let me know when you need specific feedback and/or help with specific problems.
Thanks, I think the new requirement for taking Sasha's patches is that they at least pass 0-day first before sending them to me...
As I just mentioned in the other thread, I think this is going a bit too far. Browsing through the patches, many of them don't have a stable or Fixes: tag, but just mention "fix" somewhere. It almost looks like many are being applied shotgun-wise, without real idea if the problem solved really applies to the target release.
It is quite likely that the upcoming stable release will cause a lot of regressions. This in turn may jeopardize my last two years of work trying to convince the rest of the ChromeOS team to see the benefits of stable release merges. It may put our entire stable release merge strategy at risk.
Yeah, this set is making me worried as well. I'm going to see how 0-day and your builders run on the trees today. I'm going to go have beers with Sasha tomorrow evening and we'll talk about this. I might just drop most of these from the queue...
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg Kroah-Hartman -
Guenter Roeck