On the scalability of Linus [LWN.net]

On the scalability of Linus

Posted Jul 4, 2010 4:49 UTC (Sun) by drag (subscriber, #31333)
In reply to: On the scalability of Linus by lmb
Parent article: On the scalability of Linus

Well... I know that I don't use Linus's tree on my distro. I don't use it when I am using Redhat and I don't use it when I am using Debian.

The various distributions already have taken over maintainership of their own respective kernels and have done so for a long time.

(Log in to post comments)

On the scalability of Linus

Posted Jul 4, 2010 20:38 UTC (Sun) by vonbrand (subscriber, #4458) [Link]

That isn't so. Red Hat for one used to ship extensively patched kernels, they don't do so anymore (the burden is just too high). OTOH, they do have capable people who could take over (together with the other kernel hackers, obviously) if the need should arise.

On the scalability of Linus

Posted Jul 5, 2010 10:05 UTC (Mon) by sjh (subscriber, #48103) [Link]

That is not entirely true. Red Hat does not ship patches that are not accepted upstream, but they do ship heavily patched kernels. I don't think Linus is still releasing 2.6.18, yet Red Hat Enterprise Linux 5 keeps growing new kernel based features (KVM being a notable example).

This has two good things. First, it increases the quality of the patches that Red Hat applies to the kernels it ships. Second, it means that Red Hat does not have to rebase all of those patches whenever they ship the next major release (RHEL6).

On the scalability of Linus

Posted Jul 8, 2010 13:31 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

That is not entirely true. Red Hat does not ship patches that are not accepted upstream,

They sometimes claim this, but it is not actually true. I have occasionally dug a bug fix out of RHEL 5 and sent it upstream.

but they do ship heavily patched kernels. I don't think Linus is still releasing 2.6.18, yet Red Hat Enterprise Linux 5 keeps growing new kernel based features (KVM being a notable example).

This has two good things. First, it increases the quality of the patches that Red Hat applies to the kernels it ships.

Still, they are backporting so far that there is plenty of opportunity to miss subtle semantic dependencies. For example, RHEL 5.4 added GRO but not the change to make TCP delayed-ACK work correctly with LRO or GRO.