--On January 20, 2006 11:50:32 AM -0500 Dmitry Torokhov
<[email protected]> wrote:
On 1/20/06, Michael Loftis <[email protected]> wrote:
Well there's a whole grab bag of them that I'll be getting to over the
next few months, but the most immediate is the fact that I've gotten new
hardware from a venduh that requires me to build a new Debian installer
and new debian kernels. I also have custom packages that depend on
devfs being there and now it's not.
Yes I realise this change isn't out of the blue or anything, but it's in
a 'stable' kernel. Why bother calling 2.6 stable? We may as well have
stayed at 2.5 if this sort of thing is going to continue to be pulled.
Ok, so you agree that there was an ample warning that devfs is going
away... Now, what would be different if 2.8.0 released tomorrow
without devfs and your vendor would require you to build new Debian
installer and kernel?
Because that would be expected. That constitutes a major release, and
should theoretically have had a development tree corresponding before it.
The problem is changing APIs mid-stream in what's being (or atleast been)
called a stable release.
I'm trying to think of a way to relate this better but I just can't.
What's needed is a 'target' for incremental updates, things like minor
changes, bugfixes, etc. I feel like supporting entirely new hardware
(provided that the API is 'frozen' when it's realeased mainstream) in a
stable kernel is fine, even adding features and functionality to existing
stuff is fine but without having to take the whole damned enchilada of
changes a development tree entails, which is all of the internal APIs.
Yeah, it would/will become generally stagnant tree, but that's the point of
a stable release.
It's horrificly expensive to maintain large numbers of machines (even if
it's automated) as it is. If you're doing embedded development too or
instead, it gets even harder when you need certain bugfixes or minor
changes, but end up having to redevelop things or start maintaining your
own kernel fork.
I know there won't be any change today, or right now, or maybe not ever,
but it seems to me that this is a step backwards in lk development.
Without a stable release for vendors and distros, and yes, commercial ones
at that, they either have to spend a LOT more time trying to keep track of
all the changes and pushing them out constantly to their clients and users,
it discourages development in that area, makes them go elsewhere where they
don't have to deal with this.
I'm hearing a lot from developers of embedded type systems about this
recent change in development. Though, of those, I'm probably the only one
who even occasionally pops up on LKML here.
Hopefully this last bit won't get buried in noise....
I really understand atleast some of the reasons from the kernel development
standpoint, and can see many really good reasons for running a development
tree like this, and as a method of development I like and agree with it.
However...for the general consumption there still needs to be some sort of
stable target that can be used that's 'blessed' with that mark, and will
get atleast some attention by developers for security updates and (mostly
major) bugfixes, and that people can contribute these sorts of things to,
probably with the proviso that they also contribute it to the mainline dev
kernel maybe IE if you're going to add new supported device to 'stable'
2.6.16.x then you've got to add it to whatever the current 'dev' line is
say 2.6.22 or whatever. The placing of the .'s is just symbolic. It could
be 2.6.x and 2.7.x just as in the past or it could be 3.0.0.x and 3.0.0+n
-
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]
