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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
