Re: Development tree, please?

[Michael Loftis <mloftis@wgops.com>]

(I changed the please to a lower case, I was overly punchy in the subject 
line, and I apologize to everyone for that)

--On January 20, 2006 12:11:16 PM -0500 sean <seanlkml@sympatico.ca> wrote:

> On Fri, 20 Jan 2006 09:36:35 -0700
> Michael Loftis <mloftis@wgops.com> wrote:
>
> > 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.
>
> Most of your message seems to boil down to complaining that devfs has
> been removed. Unfortunately your frustration is pointed in the wrong
> direction; you should be asking yourself why you ignored all those
> warnings about devfs removal for so long. If you really need it, just use
> the 2.4 kernel; it's very stable.

It is.  And the majority of the systems I've built (and still most new 
installs) use 2.4, but because of the need in many situations for things 
that only existed starting in 2.5 there's more argument for many cases for 
2.6 (and with some of the ARM development I've got going on there's even 
more argument for 2.6...despite the headers playing games with me right 
now....)

> If you want to complain about the current tree being called "stable",
> then just don't call it stable.   Call it the development tree because in
> the end that's what  it is.  No need to get hung up on a name; it is what
> it is.  Anyone, is free to fork a real stable tree just like some
> distributions do.   But such "stable" trees just  aren't going to be
> maintained by the same people who develop the mainline; they have enough
> to do already.

I was under the impression that the consensus has usually been multiple 
forks dividing a lot of external development resources into their own 
little camps instead of letting them all contribute to the main kernel was 
considered a bad thing?  Has this changed?  I know it's better for the 
developers....but shouldn't they or...'someone' be responsible for 
maintenance and have a place to do so?  Community maintenance? 
Developer+maintainer pairs in cases where the developer is unable or 
unwilling to actually maintain his/her code?

A target for such efforts, and community support for them would continue 
the ... 'tradition' of this being a community kernel where efforts are 
focused, and not where efforts are turned away and told to maintain your 
own forks.

> If you can think of an idea to solve your problem without demanding that
> other people  (ie. the mainline developers) do extra work, then speak up.
> But just demanding that the developers patch a stable tree while working
> on the development branch as well, has other _real_ costs that
> precipitated the shift to the current model.

Having a stable tree would atleast give me a place to commit changes to 
publicly where/if I needed to.  My main concern *today* is the devfs 
problems which I can solve yes and were known about yes, but require quite 
a bit of effort just to support the second problem of *today* which is 
Intel's latest e1000 variant.  That though is just today's troubles right 
now.  I can see others coming, and I'm concerned.

I understand the reason, but the problem it creates is it does give a lot 
of places incentive to just not contribute their bugfixes, and instead fork 
since they're not interested in getting involved in API changes 'right now'.


-
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/