civilinfrastructureplatform:cipkernelmaintenance
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
civilinfrastructureplatform:cipkernelmaintenance [2017/11/09 17:52] anniefisher |
civilinfrastructureplatform:cipkernelmaintenance [2017/12/07 14:18] Agustin Benito Bethencourt impovements in the maintenance section |
||
|---|---|---|---|
| Line 20: | Line 20: | ||
| With this release, CIP is moving towards a “shared and trusted testing” target for not just those directly involved in maintaining the CIP kernel but any kernel developer that has physical access to a board. It reduces the deployment, configuration and maintenance costs. B@D introduces a “local” approach to kernelci.org which is a distributed service centrally managed. In addition, CIP intends to increase the number of developers and organizations willing to participate in kernelci.org by providing a simple mechanism to evaluate the technologies developed by that community (LAVA and kernelci) which CIP considers upstream. For more information about the B@D v1.0, read this blog post [[https://www.cip-project.org/blog/2017/10/18/cip-launches-bd-v1-0]]. | With this release, CIP is moving towards a “shared and trusted testing” target for not just those directly involved in maintaining the CIP kernel but any kernel developer that has physical access to a board. It reduces the deployment, configuration and maintenance costs. B@D introduces a “local” approach to kernelci.org which is a distributed service centrally managed. In addition, CIP intends to increase the number of developers and organizations willing to participate in kernelci.org by providing a simple mechanism to evaluate the technologies developed by that community (LAVA and kernelci) which CIP considers upstream. For more information about the B@D v1.0, read this blog post [[https://www.cip-project.org/blog/2017/10/18/cip-launches-bd-v1-0]]. | ||
| - | ===== Maintenance policies ===== | + | ===== CIP kernel maintenance policies ===== |
| ==== CIP kernel - SLTS kernel ==== | ==== CIP kernel - SLTS kernel ==== | ||
| Line 26: | Line 26: | ||
| **When does CIP define/label a kernel as SLTS (Super Long Term Support)?** | **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. | + | New major versions of commercial Linux distributions are released at 3-4 year intervals and maintained over a 10'13 years, so that typically only 3-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. | 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. | ||
| Line 36: | Line 36: | ||
| 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 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 [[http://lkml.iu.edu/hypermail/linux/kernel/1601.1/01592.html|released on January 10th 2016]]. It was [[https://kernel.org/releases.html|declared LTS (Long Term Support) by the stable team]] which means Greg Kroah-Hartman will maintain it for two years (Feb 2018) following the kernel LTS process. Another stable maintainer could extend LTS maintenance for some time beyond that. After that period, CIP will maintain it. | + | The Linux kernel 4.4 was [[http://lkml.iu.edu/hypermail/linux/kernel/1601.1/01592.html|released on January 10th 2016]]. It was [[https://kernel.org/releases.html|declared LTS (Long Term Support) by the stable team]] which means Greg Kroah-Hartman was supposed to maintain it for two years (Feb 2018) following the kernel LTS process. In September 2017 it was announced that the 4.4 LTS branch will be maintained during 6 years. Another stable maintainer could extend LTS maintenance for some time beyond that. After that period, CIP will maintain it. |
| ==== Suitable changes ==== | ==== Suitable changes ==== | ||
| Line 62: | Line 62: | ||
| * Some features, particularly those labelled as experimental, may also be excluded from support. We have not done so yet. | * Some features, particularly those labelled as experimental, may also be excluded from support. We have not done so yet. | ||
| - | Unlike an LTS branch, an SLTS branch may include larger changes to | + | Unlike an LTS branch, an SLTS branch may include larger changes to support new hardware, to bridge the gap between SLTS branches. However, this should only be done on the newest SLTS branch. |
| - | support new hardware, to bridge the gap between SLTS branches. | + | |
| - | However, this should only be done on the newest SLTS branch. | + | |
| ==== Releases ==== | ==== Releases ==== | ||
| Line 74: | Line 72: | ||
| As we will be backporting fixes from mainline, which [[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-api-nonsense.rst|may change in-kernel APIs]], we will not guarantee API or ABI stability within an SLTS branch. It is the responsibility of members to update any out-of-tree components they use in case they are affected by such a change. However, incompatible changes to user-space APIs or ABIs will not be acceptable. | As we will be backporting fixes from mainline, which [[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-api-nonsense.rst|may change in-kernel APIs]], we will not guarantee API or ABI stability within an SLTS branch. It is the responsibility of members to update any out-of-tree components they use in case they are affected by such a change. However, incompatible changes to user-space APIs or ABIs will not be acceptable. | ||
| - | ===== Support ===== | + | Initially, CIP will release a new CIP minor kernel version every couple of months approximately. You can find the [[https://gitlab.com/cip-project/linux-cip|latest CIP kernel]] version in gitlab. |
| + | |||
| + | ===== Maintenance ===== | ||
| ==== Scope ==== | ==== Scope ==== | ||
| - | CIP maintainers will support and respond to bug reports from CIP members and their developers, but not system administrators or end users. | + | CIP maintainers will maintain and respond to bug reports from CIP members and their developers, but not system administrators or end users in general, about upstream patches. Bugs should be reported upstream. |
| + | |||
| + | 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. | ||
| - | 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. | + | For specific CIP applied patches, the default communication channel will be the [[https://lists.cip-project.org/mailman/listinfo/cip-dev|CIP-dev]] mailing list. |
| ==== Security fixes ==== | ==== Security fixes ==== | ||
civilinfrastructureplatform/cipkernelmaintenance.txt · Last modified: 2024/05/07 09:18 by nobuhiro.iwamatsu
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
