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

[Eduardo Valentin <edubezval@gmail.com>]

Hello,

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.


If this discussion is happening, I would like to be part of it. As
Amazon Linux kernel maintainer, I surely can relate with the issues of
regression introduction. And as of today, Amazon Linux does rely
on stable kernels.

Now, I am not sure if making the stable rc cycle longer would actually
improve the regression issue. As already mentioned over other emails
in this thread, longer rcs == more patches == more regressions. Given
that we set our own internal cadence, and we do not commit on releasing
every single stable rc, picking what ever is the latest rc is what we
typically do.

Also, as for the cadence of the stable branches, what I have noticed
is that having one kernel per week should be enough. However, I do
also see that there will always be cases of more than one release
per week for the embargo cases (at least based on my last observations
of LTS branches), and those usually also means we need to carry or
cherry pick patches.

With that said, I would like to see out of the discussion more on:
- What can be done to improve the regression introduction? I also
agree that regression free is a target, not necessarily achievable,
but sharing the testing strategies may be one thing to consider
to be done in rc cycles.
- What can be done to improve the embargo process and CVE managment.
- Should distro be using stable / LTS kernels?

BR, 

Eduardo

> 
> Thanks,
> Laura
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss