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 ([email protected])
"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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
