4.14.y needs commit 71546d100422b

4.14.y needs commit 71546d100422b

[Guenter Roeck]

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

Re: 4.14.y needs commit 71546d100422b

[Greg Kroah-Hartman]

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

Re: 4.14.y needs commit 71546d100422b

[Guenter Roeck]

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

Re: 4.14.y needs commit 71546d100422b

[Greg Kroah-Hartman]

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

Re: 4.14.y needs commit 71546d100422b

[Greg Kroah-Hartman]

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

Re: 4.14.y needs commit 71546d100422b

[Guenter Roeck]

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

Re: 4.14.y needs commit 71546d100422b

[Greg Kroah-Hartman]

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