Re: [Ksummit-discuss] [CORE TOPIC] Issues with stable process

[Sasha Levin <sasha.levin@oracle.com>]

On 07/14/2015 09:49 PM, NeilBrown wrote:
> On Tue, 14 Jul 2015 15:30:37 -0400 Sasha Levin <sasha.levin@oracle.com>
> wrote:
> 
>> On 07/14/2015 12:02 PM, Steven Rostedt wrote:
>>> On Tue, 14 Jul 2015 11:53:24 -0400
>>> Sasha Levin <sasha.levin@oracle.com> wrote:
>>>
>>>  
>>>>> The point I'm trying to make is that a bad patch in Linus' tree has a wider
>>>>> ripple effect than what it were in the past, while Linus might consider a bad
>>>>> patch in one of the -rc releases something minor since "no one should be using
>>>>> it for production" it really isn't the case any more, those patches can and
>>>>> will end up with the folks who don't want to have them.
>>> I have to ask, why?
>>>
>>> Just because a stable tag is on a patch it automatically gets pulled
>>> into stable? What about waiting a while before pulling in those
>>> patches? Wait till -rc2 is out before pulling in any patches marked for
>>> stable in -rc1. Then wait for -rc3 to pull in the patches that were
>>> added in -rc2. But don't pull in any patches that has a "Fixes" to it
>>> in the next -rc release.
>>>
>>> That is, when -rc2 is released, only pull in the patches marked for
>>> stable in -rc1 if there were no Fixes tags for them in -rc2. And so on.
>>>
>>> Again, just placing stuff in -next isn't going to solve this. It may
>>> help, but you will still have fixes that breaks things when they get
>>> into Linus's tree no matter how long they were in -next. This is simply
>>> because Linus's tree has a wider audience. But hopefully, the next
>>> release candidate will have the fixes for anything that breaks in the
>>> previous release candidate.
>>
>> I agree that this would be enough for -stable.
>>
>> But wouldn't you agree that the policy of not passing patches in -rc cycles
>> through -next at all is incorrect?
>>
>> I'm fine with not having a minimal time it must live in -next, but I really
>> think that it should be in -next at some point.
> 
> What exactly is the value of sitting in -next for a while.
> -next was originally to catch integration issues, and a "simple" bug
> fix shouldn't have those.
> 
> 0-day runs of -next, but then it runs on lots of other trees too.  So
> if you want 0-day coverage (which I do), then the rule doesn't have to
> "in -next" but only "in a 0-day tree".
> 
> So what, specifically, is the value that a bug-fix patch gets from
> -next that it cannot get elsewhere?

Right, -next was originally there to catch integration but this is no longer
the case: between Fengguang's tests which go beyond just building, kernelci.org
which also does boot tests on multiple platforms, and various people (myself
included) who do various testing on -next, a good chunk of non-integration
bugs is getting caught in -next before it even reaches Linus.

We could keep closing our eyes and claiming that -next is there only to deal
with the likes of merge conflicts, but reality is different and it's actually
better than what you're suggesting the intention of -next is.


Thanks,
Sasha