Re: RFC: Starting a stable kernel series off the 2.6 kernel

From: Bill Davidsen
Date: Wed Dec 07 2005 - 10:43:55 EST


Rob Landley wrote:
On Monday 05 December 2005 10:28, Lee Revell wrote:

Things like this are all too regular an occurance.

The distro should have solved this problem by making sure that the
kernel upgrade depends on a new wpa_supplicant package. Don't they
bother to test this stuff before they ship it?!?


I've broken stuff by upgrading glibc, upgrading X, upgrading KDE...

Upgrading the kernel is safer? (Anybody remember 2.4.11-dontuse?)

Yay, modular component-based design. We have standard interfaces so that stuff mostly works when you swap out different versions (or entire different components). This is cool.

But if such interfaces were actually sufficient to specify all the functionality you actually want to use, why would you ever need to upgrade a component implementing that interface to a new version?

The real problem people are seeing is that the rate of change has increased. Linus used to be a hell of a bottleneck, and this stopped being the case when source control systems took over a lot of the patch tracking, ordering, batching, and integration burden.

Automating the patch flow allowed entire subsystems to be effectively delegated (and thus the "lieutenants" layer formed and was formalized), and each of _them_ is now doing as much work as Linus used to do.

And _that_ is why there is no longer any point in -devel forks, because Linus is now fielding as many patches in a month as he used to in a year. That means in every 3 months the Linux kernel undergoes as much development (in terms of patches merged and lines of code changed) as an entire -devel series used to do. (Somebody confirm the numbers, these are approximations.)

There's no point in launching a fork that's only expected to last three months. Hence no -devel fork.

Just so we're all on the same page, I think there are two sets of unhappy people here... one is the group who want new stuff fast and stable. For the most part that's not me, although I was in the "if you're going to add ipw2200 support, why not something that works?" group. But new stuff is going in faster than most people can assimilate it if they have a real job, so I don't see too much problem there.

The other group is the people who use and depend on some feature, be it cryptoloop, 8k stacks, ndiswrapper, ipchains, whatever... which is scheduled for extinction. That's a departure from the way 2.{0,2,4} were done, where adds happened regularly, but features were only deleted in development trees. Deleting features leaves anyone who can't keep their own tree without security fixes. I see that as bed, and a far more important departure from the old model than the speed of new adds.
--
-bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/