On Sat, 21 Feb 2009 10:42:17 -0600 (CST), kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote: > This is not exactly what I was trying to say. I'll try again. > > 1. Anyone who would call himself a developer will run quite recent kernels > without being forced to do so, voluntarily and with pleasure. > > 2. Sometimes the kernel which just came out has a bug. The bug can > interfere with current work even though it is from another kernel > subsystem. I mentioned a recent example. The problem was in the basic USB > area. It specifically related to devices running on alt0 and using a bulk > endpoint. I was trying to support a camera that streams on alt0 over the > bulk endpoint. Said bug seriously interfered with progress. Who would say > that everyone should simultaneously use the same tree, suggests that > everyone should simultaneously experience the same set of bugs. > > 3. Because of (2) and for other obvious reasons, the ability to develop > a kernel subsystem semi-independently of the latest git tree is a clever > and good thing. Why give it up and tie oneself to just one git tree? > > 4. If it were my decision, I probably would not tie myself in knots if > something new would "break" a kernel which is more than a couple of > versions behind. Right now, this would probably mean I would not care at > all what happened to people running 2.6.24.x or older. Furthermore, if > what was "broken" was due to a bug in the old kernel, too bad. > > 5. So I would continue to allow flexibility but I would not become > extremely concerned if a kernel more than a couple of versions behind > would start to have problems. I would try to be nice and let people know, > unless they started to shout at me, at which point I would start to > ignore them. > > Probably all of the above would please nobody, and it is a good that I am > not in charge of anything. Actually, it would totally please me :) -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html