In the recent weeks it has become clear that we have several hardware vendors/devices that are relevant for MeeGo, but for which the supporting code is not upstream yet.
While the code is slowly making its way into the upstream kernel, each of these devices has an enormous (hundreds) list of patches, that not only make the MeeGo kernel unmanageable, they also conflict with the patch series of other vendors that are in the same position.
For this reason, we are making a change in how MeeGo (including compliance) handles the kernel for such platforms for the official release:
- MeeGo will ship with one 'reference kernel', that will have one shared codebase between all the devices it supports (with different configuration files). This kernel will be close to the upstream kernel with very few patches applied to it, and the version will be chosen by the architecture team such that the kernel is relatively recent, while still allowing for a reasonable stabilization period before a MeeGo release ships.
- For a platform to be part of this `reference kernel', the supporting adaptation code (drivers/etc) needs to already be in the upstream kernel for the version that the reference kernel uses. It's assumed that such a platform will only need a low number of small patches to fix the occasional bug.
- For platforms that cannot or do not want to use the reference kernel, a separate RPM package will be created in one of the MeeGo OBS instances. This package will be named kernel-adaptation-<platform name> to clearly mark it as separate from the reference kernel. The hardware vendor/platform enabling team for the platform will have complete ownership and responsibility for this separate kernel (adaptation kernel) package. Any team wishing to do this must identify at least one real maintainer and keep the list of active maintainers current for the duration of the required lifecycle.
- Having a separate "adaptation kernel" does not absolve the kernel owner from the requirement that all the code must go into the upstream kernel in a reasonable timeframe
- To protect the reputation of MeeGo, the owner of the adaptation kernel must ensure that security issues get fixed for the life time that the adaptation kernel is in use/supported (a minimum of 12 months after the MeeGo release)
- The adaption kernels must follow the same release process/timing as the rest of MeeGo; e.g. the same feature freeze, code complete dates etc etc.
- For MeeGo compliance and consistency, maintainers of "adaptation kernels" are required to backport any and all relevant userspace visible kernel features from the reference kernel so that applications and middleware that runs on the reference kernel can assume reasonable feature and functionality parity.
- The MeeGo compliance profile will have a set of kernel configuration options that are required to be set, in order to provide a consistent ABI and consistent functionality to the application stack.
Approved in the December 15, 2010 Technical Steering Group meeting.