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

[Laura Abbott <labbott@redhat.com>]

On 09/04/2018 02:55 PM, Guenter Roeck wrote:
> 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).
> 

Yes but with a longer -rc cycle we could have more time to actually
find those bugs before they get released and we could get more focused
testing.

> Guenter

Thanks,
Laura