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

[Guenter Roeck <linux@roeck-us.net>]

On 09/04/2018 02:33 PM, Sasha Levin via Ksummit-discuss wrote:
> On Tue, Sep 04, 2018 at 01:58:42PM -0700, Laura Abbott wrote:
>> I'd like to start a discussion about the stable release cycle.
>>
>> Fedora is a heavy user of the most recent stable trees and we
>> generally do a pretty good job of keeping up to date. As we
>> try and increase testing though, the stable release process
>> gets to be a bit difficult. We often run into the problem where
>> release .Z is officially released and then .Z+1 comes
>> out as an -rc immediately after. Given Fedora release processes,
>> we haven't always finished testing .Z by the time .Z+1 comes
>> out. What to do in this situation really depends on what's in
>> .Z and .Z+1 and how stable we think things are. This usually
>> works out fine but a) sometimes we guess wrong and should have
>> tested .Z more b) we're only looking to increase testing.
>>
>> What I'd like to see is stable updates that come on a regular
>> schedule with a longer -rc interval, say Sunday with
>> a one week -rc period. I understand that much of the current
>> stable schedule is based on Greg's schedule. As a distro
>> maintainer though, a regular release schedule with a longer
>> testing window makes it much easier to plan and deliver something
>> useful to our users. It's also a much easier sell for encouraging
>> everyone to pick up every stable update if there's a known
>> schedule. I also realize Greg is probably reading this with a very
>> skeptical look on his face so I'd be interested to hear from
>> other distro maintainers as well.
> 
> OTOH, what I like with the current process is that I don't have to align
> any of the various (internal) release schedules we have with some
> standard stable kernel release schedule. I just pick the latest stable
> kernel (.Z) and we go through our build/testing pipeline on it. If
> another stable kernel (.Z+1) is released a day later it will just wait
> until the next release based on our schedule.
> 
> Why not set your own release schedule and just take the latest stable
> kernel at that point? So what if the .Z+1 kernel is out a day later? You
> could just queue it up for your next release.
> 
> 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.
> 

Good point. There would actually be a downside of having a longer
release cycle: Fewer releases means more patches per release.
More patches per release results in more regressions per release
(if we assume a constant percentage of regressions, which seems
reasonable).

Guenter