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/12/13 18:23] bwhct [Read the commit message] Improve formatting of the command lines |
civilinfrastructureplatform:cipkernelmaintenance [2018/05/28 11:06] Agustin Benito Bethencourt [CIP kernel - SLTS kernel] |
||
|---|---|---|---|
| Line 11: | Line 11: | ||
| ==== CIP kernel - SLTS kernel ==== | ==== CIP kernel - SLTS kernel ==== | ||
| - | **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 and maintained over 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. | New major versions of commercial Linux distributions are released at 3-4 year intervals and maintained over 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. | ||
| Line 19: | Line 19: | ||
| 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. | 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?** | + | === 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 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. | ||
| Line 125: | Line 125: | ||
| * Ignore white-space changes - they shouldn't be combined with fixes, but at least they won't do any harm). | * Ignore white-space changes - they shouldn't be combined with fixes, but at least they won't do any harm). | ||
| * If a file contains multiple similar blocks of code, is the right one being patched? | * If a file contains multiple similar blocks of code, is the right one being patched? | ||
| - | * If the patch changes a function to acquire and then release a lock or other resource, are there any additional paths through the function where the resource can leak? For example, there might be an extra //return// statement in the stable branch, compared to the upstream version. | + | * If the patch changes a function to acquire and then release a lock or other resource, are there any additional paths through the function where the resource can leak? For example, there might be an extra ''return'' statement in the stable branch, compared to the upstream version. |
| - | * If the patch adds a //return//, //goto//, or //break// statement, again check for leaks. | + | * If the patch adds a ''return'', ''goto'', or ''break'' statement, again check for leaks. |
| * Sometimes the upstream commit will have been modified (backported) to create the stable patch, because it depended on new or changed APIs, or because a function that needed to be fixed has been merged or split up in some way. If it has been backported, do the modifications make sense? If someone other than the original author backported it, they should have added an explanation in the new commit message. | * Sometimes the upstream commit will have been modified (backported) to create the stable patch, because it depended on new or changed APIs, or because a function that needed to be fixed has been merged or split up in some way. If it has been backported, do the modifications make sense? If someone other than the original author backported it, they should have added an explanation in the new commit message. | ||
| * If the patch changes the type or semantics of a function, all its callers probably need to be updated. In the stable branch, there might be additional callers compared to upstream. Have any of them been missed? | * If the patch changes the type or semantics of a function, all its callers probably need to be updated. In the stable branch, there might be additional callers compared to upstream. Have any of them been missed? | ||
civilinfrastructureplatform/cipkernelmaintenance.txt · Last modified: 2023/09/28 06:49 by jki-siemens
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
