On Wed, 2013-06-19 at 17:32 +0100, Mark Brown 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
Who does the assigning, and from what pool does the assignee come?
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
Who decides when and how often the LSK code should be updated, and is the person doing the updating chosen in the same way as the original feature submission?
I'm just trying to work out if my future at Linaro is going to consiste of full time backporting of TC2 and big.LITTLE features...
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.