&gt; If there&#x27;s something that defines the Linux kernel development process is that large&#x2F;wide changes are never accepted in bulk. Changes must be broken up into independent pieces that make sense by themselves and can be well understood by the people doing the merges.<p>And that&#x27;s how you end up with clearly superior subsystem  implementations (BFQ) that linger outside the kernel as GP mentions.  Because a professor doing free work should somehow find a way to hack a cohesive working subsystem into the mess which is the old codebase so as to satisfy the maintainers (who are paid to work on this stuff) need for a gradual transition (which will eventually rip out all of the old code anyways).