Re: Development tree, PLEASE?

[Michael Loftis <mloftis@wgops.com>]

--On January 20, 2006 11:55:20 PM +0000 Russell King 
<rmk+lkml@arm.linux.org.uk> wrote:

> On Fri, Jan 20, 2006 at 04:33:38PM -0700, Michael Loftis wrote:
> > As long as it isn't wash rinse repeat, but in development kernels it
> > tends  to be.  That's the pain point.  It's not one single huge problem,
> > it's the  constant stream of little ones that we try to avoid.
>
> So what you're basically saying is that we should make zero changes
> to the kernel, because any change (even a minor bug fix) may cause
> you to need to do some work.  Should we just increment the version
> number every 3 months then?
>
> Maybe we could do this _if_ folk would stop working on the kernel,
> wanting it to run on their latest creations.
>
> The fact is that in the ARM world, everyone wants a stable kernel
> which has support for all the features in the SoC de jour that
> they're using.  That previous sentence is self-contradictory - it's
> an impossible scenario.  You can't have a kernel which supports the
> latest features without progressive and continuous change.

That's not quite what I want/need.  I want a stable kernel in all respects, 
one that has bugfixes and minor changes, for every day use, for building or 
deploying embedded systems on.  Yes for people who've got the SoC du juour 
the model is better, but for us poor buggers who couldn't give a crud about 
the latest greatest SoC it's a pain.

I think we can just let this thread die because apparently I'm in the very 
unvocal minority that is hurt and this change is costing more than others.

Right now as it sits, you have to bleed, or you don't get anything.  I 
think some more middle ground can be found...I'm just not totally sure it's 
wanted now after this line of discussion.
-
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/