docs: updates to LTS
Adding updates to LTS process -
- This is based on review comments in here -
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/34069/3/docs/lts.rst#37
- Based on discussions with other LTS maintainers.
Change-Id: Iafc606a66ea3ea69c51b433867b5025b8debebe9
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
diff --git a/docs/about/lts.rst b/docs/about/lts.rst
index 91d3d40..f5e5f8e 100644
--- a/docs/about/lts.rst
+++ b/docs/about/lts.rst
@@ -23,7 +23,9 @@
| | | answered some of the questions with feedback from |
| | | the community. |
+-------------+--------------------+-------------------------------------------------------+
- |2025-01-07 | Govindraj Raja | Convert from pdf to rst. |
+ | 2025-01-07 | Govindraj Raja | Convert from pdf to rst. |
+ +-------------+--------------------+-------------------------------------------------------+
+ | 2025-01-07 | Govindraj Raja | Updates based on learnings and suggestions. |
+-------------+--------------------+-------------------------------------------------------+
This document proposes a plan for long-term support (LTS) of the |TF-A| project.
@@ -38,7 +40,14 @@
companies want to minimize the churn when deploying fixes during incident
response, e.g. due to critical security bugs.
-This means that those companies have to maintain and backport critical updates to
+Also, the European Cyber Resilience Act (CRA) is a new EU legislation that mandates
+cybersecurity standards for products containing digital elements, aiming to
+protect consumers and businesses by ensuring manufacturers build security into
+their hardware and software throughout their lifecycle, including automatic
+updates and incident reporting; essentially requiring all digital products
+sold in the EU to meet specific cybersecurity requirements.
+
+This means that companies have to maintain and backport critical updates to
old branches internally. As this effort is duplicated across different companies
using TF-A, it makes sense to factor out this effort into a community-wide LTS.
@@ -79,10 +88,12 @@
1. For how long should an LTS release be supported?
-Linux kernel supports an LTS branch for 5 years. Since firmware tends to
-have less churn and longer lifetime than HLOS, TF-A should support at least
-5 years for its LTS. We should leave the room open for discussions about
-extending it to 7 years.
+The Linux kernel maintainers supports an LTS branch for 2 years. Since firmware
+tends to have less churn and longer lifetime than a HLOS, TF-A is trying to
+support at-least 7 years for its LTS. Initially it was intended to support
+5 years but there has been no objections to extend LTS support to 7 years.
+There are many challenges that may influence the 7 year support from CI
+infrastructure to availability of maintainers.
2. How frequently should LTS releases be made?
@@ -128,7 +139,7 @@
will be extended to cover testing for LTS as well for boards that are part of
the CI system.
-**TFTF branching**
+**TFTF Branching**
A note about testing here. After a patch is backported to an LTS branch, that
branch will need to be regression tested. Since TFTF moves forward with latest
@@ -142,6 +153,25 @@
itself to be ported to LTS. However, decision-making about those patches need
not be as stringent as for TF-A.
+**CI Scripts**
+
+CI Scripts moves forward with TF-A changes, since we need to checkout the
+corresponding release version of CI scripts for LTS.
+
+Though we are unlikely to update CI scripts, but time to time migrating a newer
+FVP version or deprecating certain tests due to unavailability of platforms may
+influence updates to CI Scripts.
+
+**Hafnium / OP-TEE**
+
+Both Hafnium and OP-TEE move forward with TF-A changes so we need to freeze their
+corresponding version from TF-A release for a LTS.
+
+**MbedTLS**
+
+Updates to the version of MbedTLS used with LTS will happen time to time based on
+maintainers call to update them or not.
+
Release details
---------------
This section goes into details of what the LTS release process will look like.
@@ -206,6 +236,10 @@
#. Reviewers should not focus too much on "what" and instead focus on "how"
#. Constantly refine the merge criteria to include more partner use cases
#. Ensure that all candidate patches flow from the main branch to all LTS branches
+#. Maintainers collaborate in the following discord channel -
+ https://discord.com/channels/1106321706588577904/1162029539761852436
+#. Maintainers discuss and provide updates about upcoming LTS releases in the above
+ mentioned discord channel.
**Options**
@@ -222,10 +256,10 @@
or candidate patch selection.
#. Monitor the main branch to identify candidate patches for the LTS branches
-#. Inform the LTS maintainers mailing list of a new candidate patch for LTS and solicit feedback
-#. Start the review process and CI/CD cycle for the patch
-#. Review the CI/CD output to ensure that the quality bar is met
-#. After reviews are complete, merge the patch and bump the minor version, if required
+#. Monitor emails from LTS triage report to choose patches that should be
+ cherry-picked for LTS branches.
+#. Cherry-pick agreed patches to LTS branches co-ordinate review process and Monitor
+ CI results.
#. Monitor the mailing list for any LTS related issues
#. Propose or solicit patches to the main branch and tag them as candidates for LTS
@@ -269,7 +303,7 @@
an LTS branch
#. The maintainers shall publish a versioning mechanism for the LTS branch
- a. Bump minor version for every “logical” `[2]`_ fix that gets merged
+ a. Bump minor version for any “logical” `[2]`_ fix(es) that gets merged
#. The CI/CD infrastructure shall provide test support for all “live” LTS
branches at any given point in time
@@ -278,7 +312,8 @@
a. notify all maintainers that a patch is ready for review
b. automatically cherry-pick a patch to a given LTS branch
c. get it through the CI/CD testing flow
- d. send nag emails to maintainers at regular intervals to ensure reviews keep moving
+ d. gentle ping in LTS discord channel asking for reviews to ensure
+ cherry-picks are merged.
FAQ
***