Linus on the BK withdrawal

Posted Apr 7, 2005 12:43 UTC (Thu) by stock (guest, #5849)
Parent article: Linus on the BK withdrawal

This must be why Linus didn't start the 2.7.xx developer tree yet.
and also why we have such weird kernel version numbers like 2.6.8.1 ..

If a tool, no matter if opensource or not, free or thousands of dollars,
is forcing you to part from your original development strategy and
roadpath, it should be thrown out.

Luckily the Linux kernel coders now have an idea how a new tool should
work, which is fine, because programming a tool is peanuts once its
design and functions are clear.

Robert

Linus on the BK withdrawal

Posted Apr 7, 2005 19:33 UTC (Thu) by proski (subscriber, #104) [Link]

This must be why Linus didn't start the 2.7.xx developer tree yet. and also why we have such weird kernel version numbers like 2.6.8.1 ..

As far as I understand, the reason is that there is enough manpower and the tools are good enough for the kernel to be developed at full speed without destabilizing it so much that it takes years to re-stabilize it.

As for x.y.z.w releases, they could (and should) have existed long ago. If a serious bug is found in x.y.z, it shouldn't force immediate release of x.y.(z+1), but it's good to have a corrected version.

For example, if I'm tracking a bug that appeared between 2.6.7 and 2.6.9, and 2.6.8 is known to kill my filesystem, I'll rather try 2.6.8.1. After all, it's unlikely that the bug I'm tracking is related to the bug that corrupts the data, but I prefer not to reinstall the OS after the test.

If a tool, no matter if opensource or not, free or thousands of dollars, is forcing you to part from your original development strategy and roadpath, it should be thrown out.

I disagree. Sometimes the strategy becomes suboptimal in presence of new tools. In particular, extensive regression tests may reduce need in beta versions. I'm not sure it applies to BK, but you are making a general statement here.

Luckily the Linux kernel coders now have an idea how a new tool should work, which is fine, because programming a tool is peanuts once its design and functions are clear.

Not always, especially when speed and correctness are important. SQL exists for years, but how much time does it take to develop a database that can compete to Oracle?