CIP announced two relevant decisions during the second half of 2016:

• At LinuxCon North America 2016 we announced Ben Hutchings as the CIP kernel maintainer. Ben is currently the Debian Long Term Support kernel maintainer and a reputed kernel hacker, specialised in kernel maintainership.
• At Embedded Linux Conference Europe 2016 we announced that our first Super Long Term Support kernel branch will be based on Linux 4.4.

When does CIP define/label a kernel as SLTS (Super Long Term Support)?

New major versions of commercial Linux distributions are released at 3-4 year intervals, so that typically only 4 versions need to be supported at one time. Given that CIP's support period is meant to be even longer, it won’t be sustainable to extend every LTS branch, but only to take on a new branch every 2-4 years.

The longer the intervals between new SLTS branches, the greater need there will be for CIP or individual members to backport new hardware support (which carries its own risks). This trade-off is perhaps the most difficult issue to decide.

CIP will measure the effort involved in maintaining the kernel branch we already labelled as SLTS (4.4) and study the technical implications of this work during 2017 in order to define when the next SLTS branch should be started.

How long will 4.4 SLTS branch be maintained?

The use cases CIP project is targeting have a life cycle of between 25 and 50 years. In theory, this is the time in which products shipped with the CIP kernel will be under maintenance. However, identifying and backporting relevant fixes becomes increasingly difficult as upstream kernel development diverges further from a stable branch. Any given SLTS branch is unlikely to be maintainable for more than 10-20 years.

The Linux kernel 4.4 was released on January 10th 2016. It was declared LTS (Long Term Support) by the stable team which means they will maintain it for two years (Feb 2018) following the kernel LTS process. After that period, CIP will maintain it.

Initially, the CIP kernel maintenance team will follow stable_kernel_rules.txt as the basis for its work. CIP will release sources, not binaries, except for the CIP platforms once we start to build a more complete platform.

Out-of-tree drivers

The embedded systems that CIP will be used in will also often require out-of-tree drivers and will sometimes include other changes of unknown quality to their kernel. These modifications are in general unsupported. If a bug is found in such a modified kernel, Members will first demonstrate that it exists in the CIP source release in order for the CIP maintainers to act on it.

Security updates

CIP works towards reducing the window of vulnerability to zero. To achieve this goal, CIP will collaborate with the wider kernel community in initiatives like the Kernel Self Protection Project and CVE.

Although this goal is achievable for CIP, its members may take much longer to release and deploy binary updates, maybe due to valid concerns about the risk of regression or limited opportunities to deploy updates. In the worst case, they may use CIP as an advertising/compliance point.