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

[Sasha Levin]

On 07/14/2015 06:46 AM, Mark Brown wrote:
> On Mon, Jul 13, 2015 at 09:02:26PM -0400, Steven Rostedt wrote:
> 
>>> But I highly doubt that having them sit in next for two weeks would change that. Again, the code that the patches fix was already in next, and the original bug was never found there. What makes you think bugs in the fix patches will be any different?
> Two weeks seems excessive but having them there for a -next build means the automated stuff has a chance to kick in which is 90% of what -next gives us in terms of quality.  The benefit does depend on how likely the change is to be affected by system/platform/config specific issues.
> 
> Indeed depending on the bug having things forced to sit in -next for too long can be a real problem - I've had people refusing to fix build errors in Linus' tree for a week as they wanted things to cook in -next which took out automated testing of Linus' tree (and anything that merged it) for the duration.

I don't agree that letting things cook in -next is hurting anyone: if it's
a critical bug then Linus should probably delay releasing a final before
it's been resolved, and if it's not then there's no harm for letting it
sit outside for a bit.

It seems that the current process is to just release at rc7/8 and deal with
breakage during the next window, consider that 4.1-rc6..4.1-rc7 had 128
non-merge commits, and 4.1-rc7..4.1-rc8 had 98. While it's a decrease, it's
not a significant one, and I don't think that anyone would claim that if
there would have been an -rc9 it would have an insignificant amount of commits.

In summary: if there's a critical bug, hold on releasing a final version If not,
leave it alone to cook in -next.


Thanks,
Sasha