4 ms·

This is a rather negative spin on something that probably is much more simple... The kernel has always been the most heavily patched package by distributors. I

by CrLf 16y ago

This is a rather negative spin on something that probably is much more simple... The kernel has always been the most heavily patched package by distributors. In the old days of Red Hat desktop, when they had a 6-month release cycle, it had maybe 10-15 patches. Now, with them having to support the same base kernel version for 7 years with bug fixes and backported features, I can only imagine how many patches it has. The line has to be drawn somewhere. At some point it stops being a somewhat patched kernel to become an effective fork. And for the major distributions it has become a fork for quite some time now. And the Linux kernel is heavily forked already. In fact, the whole Linux development model is based on particular forks by all the different subsystem groups and distributions, with periodical exchange of features and fixes between them leading eventually to the canonical Linux fork (Linus'). Today it doesn't make sense to be extracting patches from git just to produce a "tarball with patches" source RPM. It isn't a conspiracy, people. (If they started doing this to other packages, that would be another matter.)

masklinn 16y ago
The issue to your assertions is this: RedHat still uses patch stacks internally (that much is reported by RH engineers). It simply is not feasible to work on the kernel without patch stacks, unless you're OK with throwing it all away from one kernel to the next. The difference is that previously, as just about everybody else, they provided a stock kernel and their patch stacks which got applied on top of it locally. Now, unless you have a redhat support account, you only get the patched kernel, not the original one, not the patches. The patches are still there but applied on their side before distribution, it's actually more work for them to do it the new way, not less. And it generates exponentially more work for everybody else.
- CrLf 16y ago
  The people working on, say, "ext4" also have to maintain their own patch stack in the form of a git repo. How to they manage to do that while still being able to go from one kernel to the next? How is that different from what Red Hat does?

by CrLf 16y ago

masklinn 16y ago

The issue to your assertions is this: RedHat still uses patch stacks internally (that much is reported by RH engineers). It simply is not feasible to work on the kernel without patch stacks, unless you're OK with throwing it all away from one kernel to the next. The difference is that previously, as just about everybody else, they provided a stock kernel and their patch stacks which got applied on top of it locally. Now, unless you have a redhat support account, you only get the patched kernel, not the original one, not the patches. The patches are still there but applied on their side before distribution, it's actually more work for them to do it the new way, not less. And it generates exponentially more work for everybody else.

CrLf 16y ago
The people working on, say, "ext4" also have to maintain their own patch stack in the form of a git repo. How to they manage to do that while still being able to go from one kernel to the next? How is that different from what Red Hat does?