Felipe, Sorry to say but to say that one has to migrate to latest kernel in order to get community support is not right....the statement does has a touch of arrogance. You are not the spokeperson for the community. On Thu, Jul 31, 2008 at 4:02 PM, Felipe Balbi <me@xxxxxxxxxxxxxxx> wrote: > Hi, > > I hope we end this thread some day... > > On Thu, Jul 31, 2008 at 01:38:59PM -0700, Emanoil Kotsev wrote: >> Kernel developers should fix bugs in minor kernel versions as they are meant for this purpous and do major changes only in major version. A bunch of bugfixes I see (not only usb related) are just not in place in minor kernel versions. That's my opinion at first place. >> >> Second if you want to have me as happy linux user developers should agree to support older versions to help embeded and other developers working further on their projects. >> And I'm writing this because (also in other forums) people tend to have such a neglecting mentality ignoring the needs of others. Just to remember the reason for this discussion was the statement that 2.6.22 was too old, which as Anand pointed out was in it's latest release was issued in the beginning of the year. This is really "windows like" mentality and as Anand says at least they support the versions they issue - sorry for this - but I think it's kind of truth. >> > > 2.6.22 was in Jul 2007, he pointed out a minor stable version out of > 2.6.22. > >> > > And yes I'm planing to try 2.6.26, but I'm >> > pretty sure that there >> > > would be issues with drivers like uvcview, the >> > proprietary ATI and >> > > NVidia and apps like skype >> > >> > Closed source drivers have issues, film at 11. Bah, take >> > it up with >> > them, there is NOTHING that us developers can do about >> > that, sorry. >> >> You are neglecting the point and kind of insulting me! So you think I should spent my time convincing about 20 people from different companies to recompile their software because I was told by you to upgrade to fix a usb issue or a kind that is not related to their software and when they finally do it there is a already a new kernel version ... sorry I can not agree with any of you on this point. You want me to spent my time contacting people and not working on my projects ;-) > > You are really missing the whole point of the discussion. > > The driver in question is musb, which is not closed source at all. > Closed source drivers is a different issue and Linux kernel is said that > won't provide a stable API. It's always changing. > > Really, musb driver _has_ changed since 2.6.22 and that special 2.6.22 > version was coming from a vendor we cannot support vendor kernel. We > support linux mainline git tree, that's all. > > I just asked why using that version, I didn't ask nobody to upgrade. But > really, all the changes made from 2.6.22 until now would make any musb > patch from 2.6.22 to be unaplicable to recent musb code, besides, > *again* it might be that the particular bug could have been fixed in all > those set of changes in musb driver from 2.6.22 until now, so why > spending time trying to fix again something that might have been fixed ? > We could only backport that particular bug fix to 2.6.22. > >> Why just not be able to patch my old kernel without breaking the ability to use the software I already have installed and is working with the version I use? > > You can do it, but you cannot expect that your patch get accepted, it > might even not apply and that was my point. > >> I think this is the question no body wants to answer and I think there is a problem with you guys. What are you doing this development if some people are not happy with it and have reasonable arguments. > > Talk for yourself, don't "broadcast" it. > >> May be the patches should be split into smaller files related to bugs - just an idea! >> You experience a bug and patch - the bug is gone you are happy. >> May be there should be some longer period to support at least the latest stable releases ... but something should be done. > > If the api has changed you cannot expect that. Specialy if you're using > vendor-specific kernel, it doesn't matter if it's nokia, redhat, ubuntu, > TI, etc. > >> > Applications are a different story, they should "just >> > work" with >> > different kernel versions, there should not be any problems >> > there. If >> > there are, let the kernel developers know, we take >> > backwards userspace >> > compatiblity VERY seriously. >> >> gcc-4.3 ;-) is it application or what do you mean ... the compiler is not an application ;-) > > And it works it doesn't matter the kernel is running below it. If it can > generate good binaries or not it's a different story. Has nothing to do > with kernel, it's a gcc-related issue, don't you think ? > > Anyways, this thread is already way too big. > > -- > balbi > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
