On Thu, Jun 20, 2013 at 10:29:43AM +0800, Andy Green wrote:
Hi Mark -
Please don't top post on upstream style lists such as this one.
- At the moment the Landing Team kernels all (?) use llct as a basis.
From there on top of mainline we get some upstream-headed things, and some less upstream-headed things like Androidization.
So in addition to having this backport-focused "clean" mainline tree, someone, probably Andrey, will need to look after a "flavoured" llc-LTS version which follows your mainline -focused tree but has the best updated versions of the original llct content as well. Depending
Is there some use case of the LTS kernels where someone would want to do this? I don't think I'm aware of it if there is.
- I'm not sure there's anything to do about it but having an LTS
kernel at all also generates a new tension between tracking at the member, and the desire to forget about that irritating work of keeping their patch load and kernel current and "getting lost" in the LTS version until the next LTS version. We've experienced being asked to do that and no matter the reasoning, you end up with a rotting pile of unmaintained patches with nowhere to go, no matter how good back in the day (cf, tilt-3.4). So it's a worry people look at the LTS kernel and don't understand why they should bother keeping their kernel and OOT patches up to date and at least with the possibility to be polished and offered to mainline.
This is happening anyway and will continue to happen for the forseeable future in the consumer electronics space, it's just a function of shipping product on something other than -next really. I'd actually hope that our strong policy on using upstream code and backporting it might help a little here, keeping things more in sync. It's not a particular problem to work on a backport for a product so long as the backport and upstream are reasonably in sync.
- Once people who don't fully understand the issues get a taste of
backport candy, it becomes the answer to everything, for example, "we have so much investment in 3.0 let's backport big.LITTLE support to that". That kind of thing just digs the grave deeper and wastes engineering resources, so I hope (given who's doing it, actually, I assume ^^) we have a calibrated approach in mind for NAKing things that someone may have gotten themselves in a position they really want, but which definitely go in a bad direction for everyone, even the people asking.
I don't think the people you're worrying about here have any intention of running a LTS kernel directly, the broad plan is that they will take the LTS and use it as a basis in the same way they currently do with upstream.
The investment in old kernels thing that you mention is not really an issue these days thanks to Android, it's got people used to an upgrade cycle. The reason people standardise on v3.4 right now is more things like being more comfortable using whatever Google were using for their lead device and it giving all the component makers a target to aim at so the product people don't have integration hassle.