Re: Development tree, PLEASE?

[Jan Engelhardt]

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

So let's rename 2.6.16 to 2.7.0, plus:

 - (implicitly with the *rename*) stop the 2.6.x series

 - never use 2.<even>.x again
   (some people still don't seem to get that <even> does not mean
   "stable" in the 2.4 sense)
   - or start 3.x with an overall new counting scheme

 - follow the current development model as usual

> 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


Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/