4 ms·
This is the opposite of how it worked. Again, I left a couple of years ago, but the methodology was "get a bug/RFE downstream, reproduce upstream if it's still
by evol262 4y ago
This is the opposite of how it worked. Again, I left a couple of years ago, but the methodology was "get a bug/RFE downstream, reproduce upstream if it's still there or implement the feature, get it through code review and merged into the codebase, cherry pick it into RHEL, making whatever changes are necessary".
Fedora is approximately as "vanilla" as Arch. If any patch was in a Fedora package which you had to pull out, it's because upstream did not accept the patch for some reason, but the maintainer decided it was critical enough to diverge. This isn't/wasn't SOP.
The Linux kernel patches are, as above, not really where they make money, which is consulting. But there is no such thing as an "upstream stable release" which Red Hat contributes to in any meaningful way.
Kernel features which are going to go into Fedora go into mainline. Not the LTS release. RHEL's support policy has a somewhat strict SLA on kernel ABI/API, and their support cycle is much longer than upstream "LTS" which "everyone else" (whomever that is, because Canonical and SuSE have policies similar to Redhat) uses.
Patches are cherry picked from mainline not to the "upstream stable" release, but to whatever version of the kernel RHEL-whatever shipped with. 2.6.18 for RHEL5, 2.6.32 for RHEL6. Forever. It has been this way essentially forever is not a new change, has nothing to do with excluding the rest of the community and everything to do with the fact that it was the only way that nvidia/emulex/whatever_hardware_vendor would agree to support Linux AT ALL. They were not going to rewrite their driver for RHEL3.5. Just RHEL3, now and forever so the ABI had to stay the same.
The patchset is publicly available as part of the SRPM, and as a raw .patch file. It is not individual patches anymore because Oracle was cherry picking patches from their cherry picks to repackage Redhat's source and poach customers.
It was moved to a single, enormous patch file so Oracle's kernel engineers actually had to work to integrate their ksplice/RAC/whatever patches, but that's politics.
- eska 4y agoYou can whitewash history all you want, but kernel maintainers hated working with the pulseaudio team. This went so far that even Linus gave that team an Nvidia-caliber piece of his mind.
- evol262 4y ago> project maintainers and project contributors don't agree. News at 11 This is just open source. "kernel maintainers hated working with the pulseaudio team" is not news any more than "Theo de Raadt/Ulrich Drepper dislike some ideas of others". It is part and parcel of open source development. It doesn't need 'whitewashing'. This is how quality software is built. Conversely, even referencing that the LKML was full of angry messages (again, LKML having drama is like the sky being blue) about pulse (or kdbus from the systemd team, which is also a thing) is just evidence that Redhat did and does work with upstream rather than having some walled garden which they jealously guard from the rest of the community.
- makomk 4y agoForgot to mention the best part - as far as I could tell, the package maintainer basically was upstream at the time. (I think both might have been maintained by Poettering himself, but it was a long time ago.) So in order for patches not to make it upstream the same person had to decide that it was important enough to diverge from the upstream release but not important enough to fix for everyone else. Oh, and one of the times I ran into this involved a seemingly really easy to reproduce crash (at startup, if I recall correctly) in a released upstream version...