On Tue, Feb 12, 2008 at 10:26:53AM -0800, Linus Torvalds wrote:
Nope, never.
Not it isn't. To quote you a number of years ago:
"Linux is evolution, not intelligent design"
We need to constantly be able to make these kinds of changes in order to
continue to remain relevant.
Oh, it's been painful at times, but they are, overall, very rare.
If you look at the rate of change we are currently running at, it's
amazing that we do not get _more_ of these kinds of problems.
Remember, we are currently clocking along at the steady rate of:
4000 lines added every day
1900 lines removed every day
1300 lines modified every day
And the rate of change in each major portion of the kernel (drivers,
arch, core, network, etc) is exactly proportional to the amount of the
kernel that that portion takes up (I have detailed numbers if people
really want to see them.)
Because of this rate of change, we are surviving, and evolving into what
is exactly needed at this point in time from a kernel. To try to quench
this change, and force us to stick with things that are no longer
optimal, is going to cause us to make the same mistakes that AIX and
Solaris and Vista have. To stop this, is to die :)
We have done very good at that. The problem comes in when one subsystem
depends on another one.
Like the kobject core, or driver core. Or network core. Changes there
trickle out into the other portions of the kernel that depend on them.
And we fix them up, and move on. And so far, we're doing this very
well, at a rate faster than any other software project ever has.
I strongly disagree here. We lived with that kset/ktype crap for years,
and I finally broke down and cleaned it up, simplifying things, removing
code, making the kernel smaller, leaner, and easier for others to change
and use in the future. With your statement, such a change should have
never taken place as it what we had at the time was "not optimal", but
good enough to live with.
They usually don't, by virtue of our current development model and how
we have the kernel structured.
But they do happen about once or twice a kernel release, just by virtue
of the way things need to happen. And since the last kernel had 10353
different commits, only 2 conflicts is a pretty good rate of merge
issues :)
And when they happen, so far _everyone_ involved instantly rushes to fix
them up. I say the fact that we are able to detect these problems, fix
them, and continue to move on and work, is a testament to the fact that
our current model is working _very_ well.
I think that you aren't seeing all of the "whacks" that Andrew is
constantly giving us that break his -mm tree with problems at times, so
when it gets to you, things are cleaned up.
The goal of -next is to take that "whacking" chore off of Andrew's
shoulders, and onto others, so Andrew can move off doing something like
development better.
My point is that the -next tree needs to work like -mm does today, a
policy of "merge broke, drop the tree" isn't going to help us subsystem
maintainers out in the end, we need a way to shim it up for a while as
merges and other communication happens, just like -mm provides, so that
when we get to the 2 week merge window, things are properly worked out
and what goes to you is all clean and purty.
thanks,
greg k-h
--
