On Mon, Jul 11, 2005 at 06:15:35AM +0200, Jakob Bohm wrote: > On Sun, Jul 10, 2005 at 11:49:22AM -0700, Greg KH wrote: > > On Sun, Jul 10, 2005 at 12:56:52AM +0200, Jakob Bohm wrote: > > > > > > Am I understanding you correctly when I read it as saying that kernel > > > 2.6.12 > > > (a point release in the "stable" branch) > > > > There is no more "stable" or "development" kernel branches anymore, > > haven't been for quite some time. So this statement is false. > > I was aware that a more aggressive change policy had been decreed for the > 2.6.x series and that 2.7.x had not yet been started. I was not aware that > the whole idea of starting a truly experimental branch (2.7.x or whatever) > later had been abandoned. But thanks for the info, it only reinforces one > of my points.
What point would that be? > > > and (from info elsewhere) simultaneously drops support for devfs (to > > > which people just finished migrating their locally written scripts > > > ...)? > > > > devfs has just been removed from the main kernel tree. If you all are > > just starting to add support for it, you are all pointless behind the > > times. > > Again confirming what I said. The decision to drop devfs as of 2.6.12 did > not reach us users until about a year ago. And a _year_ isn't long enough time? What would be an acceptable ammount of time for a kernel feature that does not work and has not been maintained for about 3 years? > Converting thousands of tools, > scripts (upstream sources, distribution packages, local sysadmin scripts, > even files such as /etc/fstab) on each and every system had then (a year > ago) just been completed (not started). For good reasons. > At that time, 2.6.x was relatively > new, devfs was supported in both 2.4.x and 2.6.x and its naming scheme was > no longer being changed at irregular intervals. What naming scheme has been changing? udev's hasn't. devfs's hasn't. > Not so with udev. A year ago. Then the word came down: devfs is > going to be removed! Move to udev! All your work is wasted! udev supports devfs naming schemes if you want to use that instead. No breakage happens. Becides the devfs naming scheme is not LSB compliant, why would you work to implement support for such a broken scheme? > Debian does a very thorough and careful QA and integration on packages and > has traditionally had a great focus on backward compatibility, however this > natural creates a delay before major upstream events reach the user end of > the pipeline. Debian's development cycles have no relevance on this, sorry. > Full support for running Debian on kernel 2.6.x at all was not declared > release ready until June 6th 2005, and just in case that release included > kernel 2.4.27 as a fallback option. I am well aware of Debian's kernel support, and the mess that it currently is. Along with the mess that the current long development cycles have caused. That was not my point here at all, I was only stating that your comments about udev and the kernel were incorrect. > Some people live on the bleeding edge, others wait for things to stabilize > and the kinks to be shaken out of systems first. And for us, killing such a > pervasive API needs a longer notice than a year or two. What pervasive API? As Debian seems wed to 2.6.8, devfs is still there, you can still use it. thanks, greg k-h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
