Hi Mark -
It sounds good to me.
There's some extra things to consider in terms of internal consumers of this tree though. They're probably Andrey's problems not the LTS kernel directly but we should discuss.
1) 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 on what the original llct merges were, LTS maintenance of those may look like swapping out the original series for backporting the actual series of the same patches that went upstream, because those are the ones that will get fixes going on.
One way to do that is retain the original merge sources and Andrey recomposes on top of the LTS kernel each update... that makes it easy to swap out the content of the series he is merging, and it should be fairly turnkey most of the time because almost everything is normally locked to the same version that it all applied to originally.
2) 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.
3) 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.
-Andy
On 20 June 2013 00:32, Mark Brown broonie@linaro.org wrote:
This is a first draft at a process for getting things integrated into the Linaro Stable Kernel releases. Any feedback is appreciated, hopefully this is all fairly boring and uncontroversial so there shouldn't be too many surprises.
The first thing to say here is that all LSK releases will be based off the latest generic Linux stable kernel so the best way to get a change into a Linaro release is to get it into the generic Linux stable kernel using the standard processes. This will maximise the number of people who can use the change and is just generally good practice.
New features
Features for the stable kernel are agreed by the TSC. Once a feature has been agreed by the TSC there should be an owner assigned to deliver a feature branch into the stable kernel and work with the stable kernel team to resolve any integration issues at least up until the feature has been included in a release. This will be done per kernel version.
These feature branches should be based on the relevant upstream kernel as far as possible (any dependencies on other branches should be discussed with the stable kernel team). Some information about where the code came fromm should be included along with the code, in order of preference:
1. Commit IDs from the standard kernel in the changelogs of the individual patches. 2. A description of how the equivalent change was made upstream or why it isn't required in LSK (eg, explaining that this is taken care of by features not present in the stable kernel). 3. References to where out of tree development is happening including contact information for followup.The code should be sent as a pull request or patches, with review by the stable team following normal kernel process and focusing on backporting and integration issues. Relevant testing infrastructure should also be available in LAVA for QA and the review will also include ensuring that the testsuite passes with the changes integrated.
Once the code has been accepted it will be stored as a branch in the LSK tree and the submission branch can be deleted.
Updating code in the LSK
The LSK can be updated either by replacing an existing topic branch or by submitting incremental patches. Replacement would be most useful in cases where a feature has not yet been merged into the standard kernel and is still being redeveloped there but otherwise incremental updates are preferred. The process for submitting changes is the same as for new features with the exception that incremental updates should be based on the topic branch in the LSK git rather than the standard kernel.
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel