Re: Development tree, PLEASE?

[Michael Loftis <mloftis@wgops.com>]

--On January 20, 2006 11:50:32 AM -0500 Dmitry Torokhov 
<dmitry.torokhov@gmail.com> wrote:

> On 1/20/06, Michael Loftis <mloftis@wgops.com> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/