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

Sasha Levin sasha.levin at oracle.com
Tue Jul 14 19:30:37 UTC 2015


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.



Thanks,
Sasha


More information about the Ksummit-discuss mailing list