Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

At least in my group, the backports are hand picked to solve specific problems, not just random wholesale backports.


For the duration of a major release, up until ~x.4 pretty much everything from upstream gets backported with a delay of 6-12 months, depending on how conservative to change the rhel engineer maintaining this part of the kernel is.

After ~x.4 things slow down and only "important" fixes get backported but no new features.

After ~x.7 or so different processes and approvals come into play and virtually nothing except high severity bugs or something that "important customer" needs will be backported.


Sadly, 8.6 and 9.2 kernel are the exception to this. Mainly as they are openshift container platform and fedramp requirements.

The goal is that 8.6, 9.2 and 9.4 will have releases at least every two weeks.

Maybe soon all Z streams will have a similar release cadence to keep up with the security expectations, but will keep a very similar expectations that you outlined above.


Sure, they aren't backporting patches wholesale. But the patches that did get backported, if any, needs much more scrutiny given the situation.

The thing about enterprise Linux distros is that they have a long support period. Bug fixes and security patches pile up.

Fortunately though, xz doesn't seem to have a lot of backported patches.

https://git.centos.org/rpms/xz/blob/c8s/f/SPECS/xz.spec https://git.centos.org/rpms/xz/blob/c7/f/SPECS/xz.spec

But take glibc for example. The amount of patches makes my head spin.

https://git.centos.org/rpms/glibc/blob/c8s/f/SPECS/glibc.spe...




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: