Re: Development tree, PLEASE?

[Michael Loftis <mloftis@wgops.com>]

--On January 20, 2006 5:41:13 PM +0100 Jan Engelhardt 
<jengelh@linux01.gwdg.de> wrote:
> > Lots of things still out there depend on devfs.  So now if I want to
> > develop my kmod on recent kernels I have to be in the business of
> > maintaining a lot more userland stuff, like mkinitrd, installers, etc.
> > that have come to rely on devfs.
> Just like the OSS-ALSA/e100 debate: If there IS something that you
> do not like [something that requires devfs], why has NO ONE objected?
> (Quoting Greg: "and I have not heard a single peep out of anyone about
> the  email titled "Subject: devfs going away, last chance to complain"")
> Not to  forget there is ndevfs if you really need it.
Unfortunately I wasn't pushing on bleeding edge kernels when that thread 
happened and I apologize for not speaking up then, but this is much larger 
than just devfs.  This is the need for development to get off the stable 
kernel, and onto a development branch where it belongs so we can quit 
breaking things for the stable kernel.  Unless the intent is to just not 
have a stable kernel anymore.  If it is, then fine, lets see word from the 
forces that be along those lines.
I'm just calling things as they are, right now, 2.6 is development, and 
unstable.  Yes it runs without crashing and is stable in that sense, but so 
are a goodly lot/most of the 2.5 series (heck I ran a decent chunk of that 
in production).
The problem here is I'm spending a lot of my time lately fixing things that 
shouldn't need fixing.  Things that are/were developed against what was 
supposed to be a stable major version and has been turned into a 
development version.
I realise that there are/have been policy changes, and I can see the need 
and reason behind those, and I agree with them on the front, more 
development is good.  But it should be done in a development branch, 
because otherwise it makes it damn near impossible to maintain when the 
world is slowly changing under you.
It's easier for an embedded system especially to pick a target, and then 
stay with it.  Later when a new major version comes out the time can then 
be invested ONCE to redevelop what needs redeveloping, which is easier to 
do (yes I'm speaking from a business standpoint, sorry, but someone has to) 
and to sell to management than nickel-and-dime to death of trying to follow 
a development tree.
-
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/