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

[NeilBrown]

On Tue, 14 Jul 2015 22:09:50 -0400 Sasha Levin <sasha.levin at oracle.com>
wrote:

> On 07/14/2015 09:49 PM, NeilBrown wrote:
> > On Tue, 14 Jul 2015 15:30:37 -0400 Sasha Levin <sasha.levin at 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 at 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.

But 0-day doesn't *only* pull from -next.  Neither (as far as I can
tell) does kernelci.org.

Maybe I'm suggesting that it is wrong to add all this extra meaning to
linux-next.
It is definitely good to have this extra testing before code gets to
Linus.  It is definitely good to encourage people to make use of it.
I'm not sure that directing everything through -next (which has a delay
because it is curated by a human) is the right approach.

I want bugfixes to go quickly though automated tests (and 0-day is
delightfully quick - no need to wait for morning in .au for -next), and
then to Linus to sit for an extended time to be tested by the army of
beta-testers (who try things that no automated test would ever think
of).

Thanks,
NeilBrown