I do understand that dumping "ancient" kernel support would make things a lot easier. But, in the embedded system world, upgrading kernel isn't that easy like in PC world. Most of those systems put to market today has 2.6 kernels, and backports project is a great job and it will revive so many systems if it keeps the tradition to support down 2.6.24 as its predecessor. Best regards, Harrison > On Fri, Apr 11, 2014 at 11:45 AM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Fri, 2014-04-11 at 11:23 -0700, Luis R. Rodriguez wrote: > > > >> compat-drivers is ancient as well, the new project is backports and > we > >> will be deprecating older kernels to help us scale better. > > > > I know I pushed for the 2.6.24 deprecation, but do you see any > > particular issue with other kernels < 3.0? The 2.6.24 was big and > ugly, > > but none of the other ones seem particularly big/ugly, and there > aren't > > a ton of patches either ... > > On my current not published commit in which I've axed out all older > kernels its allowed me to rip out all the patches which were not split > up atomically and reshuffle and order every single series we have into > the new 4-digit form which implies they are atomically well split. > This can enable us to push for clean architecture on patches moving > forward. > > > Now, I'm all for dropping support if it really makes a difference, > and > > we might want to drop them from the ckmake tests to reduce the pain, > but > > I'm not entirely sure we should wholesale remove things if there are > > still users for them out there. > > I think this makes sense if we had an easy way to break things out as > optional right now but we don't, and given that some older patches > weren't really atomic (consider bluetooth for pre 3.0) it would mean > carrying around a pile of mess as optional but to what end if we're > never applying it? What type of review can we expect from these > patches if they are really not maintained? Let's also consider now the > gains of being able to help persuade folks to upgrade if we also > embrace a sensible policy for what kernels we support. One of my goals > is to grow backports with more drivers and new options (in-kernel > support) but if backports can also be used as a carrot to help with > moving the ecosystem forward, I think its a strong element to > consider. So there are two gains here: helping us clean up things, and > setting up a sensible policy that aligns with kernel.org releases / > maintenance cycles. > > Luis > __________ Information from ESET NOD32 Antivirus, version of virus signature database 9667 (20140411) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
