On Tue, Oct 8, 2019 at 4:51 AM Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
Laura Abbott schrieb am 16.09.19 um 16:24:
> Kernel 5.3 was released upstream yesterday Sept 16. Fedora will be
> following the same rebase schedule as with past kernels. This means
> F30 will be rebased to 5.3 first followed by F29 shortly thereafter.
> We typically wait until the 2nd or 3rd stable release to push a
> rebase. Based on past timings, I'd expect this to happen around
Would it be wise to tighten the "same rebase schedule as with past
kernels" a little bit in the future (maybe by one week)?
Just wondering, as it seems the fast few transitions from one version
line to the next iirc all finished some time after a line went EOL. This
time it looks worse: 5.2 is EOL as of today and 5.3 hasn't even hit
updates-testing for the current Fedora release yet afics. And the
stabilization copr wasn't much in action this time either.
But whatever, I assume there are reasons why things are a little bit
more bumpy this time, that not why I'm writing this mail. I was just
wondering if a slightly faster schedule for the rebases might be a good
idea in general.
I'll take the contrary position :-) I haven't dug into what happened
over the weekend with upstream kernel development, but they went from
5.3.2 to 5.3.5 in just a few days. And then a ton of backport bug fix
stuff landed over the weekend in all stable kernels, I saw things from
July in the changelog, even for 5.3.
I play kernel roulette, currently running
5.4.0-0.rc2.git0.1.fc32.x86_64 on F31, so I've signed up for kernel
churn. But most everyday Fedora users silently appreciate not having
to bother with it. Anyone else can 'dnf install *rpm' any kernel they
want, if they want to opt into their own rebase. It's not a problem to
run F31 kernels on F30. I've been doing that for years, to the point I
now wonder if it'd be possible to have my usual dnf update only ever
install Rawhide kernels, while keeping everything else on the current
release. Automatically. *shrug*
5.2.20 is building only a day after release, and I think it's
completely reasonable for Fedora 29 users to use that for a couple
weeks, baring some major discovery. Anyone still on F29 is more likely
to get perturbed with either churn or regressions - quite a lot of
Fedora users are using laptops, in contrast to upstream testing so
it's decently likely laptop related regressions get discovered later
than automated tests will reveal. Most people aren't that interested
in discovering and reporting kernel bugs, they have other work to get
I don't know if it's useful to figure out a way to get x86 kernels
into u-t faster? If it were split out somehow, maybe it'd show up 4-6
hours earlier? e.g. right now if you check the kernels building, the
5.3.5 fc31 meta package, or whatever it's called, isn't done because
armv7 is still building. The rest are done and can be downloaded
already from koji, but not through u-t. But yeah, not sure if this
would be an effective use of resources.