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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2015-07-15 at 12:28 +1000, NeilBrown wrote:
> On Tue, 14 Jul 2015 22:09:50 -0400 Sasha Levin <sasha.levin@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@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.
> 
> 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).

OK, granted 0day runs on all branches, not just for-next; but how do you
know it's run?  If all tests passed, you don't get a success report.
I'd be happy skipping linux-next for 0day if I knew it had run.

I just use the rule of thumb: must be in -next for two days because then
I know 0day (and the other checkers) have also run.  Effectively this
means that all -rc fixes have to be in by Thursday for the Sunday -rc
release.  Anything after Thursday goes in the next -rc.  Even if I'm
waiting only for 0day, the rule means I know it's run.

I don't consider this to be an onerous delay and it has, on occasion,
caught bogus fixes.

James