Linus on the BK withdrawal
Posted Apr 7, 2005 19:33 UTC (Thu) by proski
In reply to: Linus on the BK withdrawal
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 22.214.171.124 ..
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 126.96.36.199. 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?
to post comments)