On Mon 2018-04-16 16:45:16, Sasha Levin wrote:
On Mon, Apr 16, 2018 at 06:42:30PM +0200, Pavel Machek wrote:
On Mon 2018-04-16 16:39:20, Sasha Levin wrote:
On Mon, Apr 16, 2018 at 06:28:50PM +0200, Pavel Machek wrote:
> Is there a reason not to take LED fixes if they fix a bug and don't > cause a regression? Sure, we can draw some arbitrary line, maybe > designate some subsystems that are more "important" than others, but > what's the point?
There's a tradeoff.
You want to fix serious bugs in stable, and you really don't want regressions in stable. And ... stable not having 1000s of patches would be nice, too.
I don't think we should use a number cap here, but rather look at the regression rate: how many patches broke something?
Since the rate we're seeing now with AUTOSEL is similar to what we were seeing before AUTOSEL, what's the problem it's causing?
Regression rate should not be the only criteria.
More patches mean bigger chance customer's patches will have a conflict with something in -stable, for example.
Out of tree patches can't be a consideration here. There are no guarantees for out of tree code, ever.
Out of tree code is not consideration for mainline, agreed. Stable should be different.
This is a discussion we could have with in right forum, but FYI stable doesn't even guarantee KABI compatibility between minor versions at this point.
Stable should be useful base for distributions. They carry out of tree patches, and yes, you should try to make their lives easy.
Pavel