[Ksummit-discuss] [MAINTAINER SUMMIT] Stable trees and release time

[Jiri Kosina]

On Tue, 4 Sep 2018, Sasha Levin via Ksummit-discuss wrote:

> This is exactly what would happen if you ask Greg to go on some sort of 
> a schedule - he'll just defer the .Z+1 commits to what would have been 
> the .Z+2 release, so you don't really win anything by moving to a 
> stricter schedule.

You potentially do win one thing, and that's review (or at least 
possibility of review).

With current cadence, I'd put all my bets on the fact that everybody is 
just completely ignoring the e-mails about patches being queued for stable 
inclusion. It's just way, way too many of them, it's a neverending, 
contignuous, overwhelming stream.

If this would be happening at smaller cadence, chances of people (original 
patch author, reviewers and maintainer) actually investing brain energy 
into evaluating whether particular patch is suitable for particular stable 
without introducing backporting regression would be much higher.

Also, it's not only the cadence, but the patch selection criteria that 
contributes to killing the review of stable patches; the bar for stable 
tree acceptance is much lower than it used to be (really, just look at the 
criteria formulated in stable-kernel-rules.rst and then match them against 
the patches that actually land in the tree); so we'd need both, otherwise 
I think the trend of distros moving away from stable is inevitable (as "no 
review" basically equals "we're not obsessed about regressions", and 
distros don't want that, I think).

But then, yes, it might be that that's actually not a problem :)

Thanks,

-- 
Jiri Kosina
SUSE Labs