docs/about/lts.rst

17   |             | Varun Wadekar      | made by both authors, cosmetic changes to the content |
22   | 2022-08-05  | Varun Wadekar      | Changed the “Future plans” section to “FAQ” and       |
26   | 2025-01-07  | Govindraj Raja     | Convert from pdf to rst.                              |
38 when a product is released, the companies have to support that in-market product
39 such that the amount of changes to the firmware are kept to a minimum to avoid
40 the risk of regression. At the same time the companies don't want to exclude
42 companies want to minimize the churn when deploying fixes during incident
43 response, e.g. due to critical security bugs.
46 cybersecurity standards for products containing digital elements, aiming to
50 sold in the EU to meet specific cybersecurity requirements.
52 This means that companies have to maintain and backport critical updates to
54 using TF-A, it makes sense to factor out this effort into a community-wide LTS.
61 - criteria for selecting patches which will be backported to LTS branches
66 We must have an objective criterion for selecting patches to be backported to
69 a. there will be less -- ideally no -- discussion when selecting patches to backport
76    is automatically selected for back porting. This includes patches to external
81    the specific platform that the fix applies to.
94 tends to have less churn and longer lifetime than a HLOS, TF-A is trying to
95 support at-least 7 years for its LTS. Initially it was intended to support
96 5 years but there has been no objections to extend LTS support to 7 years.
98 infrastructure to availability of maintainers.
103 cycle, it would make sense to have yearly TF-A releases.
110 with Android releases which tend to fall in Q3 each year. Since product
111 releases are timed with Android release, this gives enough time to harden
119 5 years and we can discuss extending it to 7 years later on. The LTS release
124 Every patch merged to the LTS branch will complete the following tests before
138 Currently TF.org maintains a CI system to run TF-A automated tests on a
139 selection of HW boards donated by TF.org members (a benefit reserved to project
141 will be extended to cover testing for LTS as well for boards that are part of
146 A note about testing here. After a patch is backported to an LTS branch, that
147 branch will need to be regression tested. Since TFTF moves forward with latest
148 TF-A changes, newer TFTF tests may not apply to old LTS branches. Therefore
149 TFTF will also need to be branched, in-sync with TF-A LTS branches. In other
150 words, there will be one TFTF LTS branch corresponding to each TF-A LTS branch.
151 The TFTF LTS branch will be used to regression test the corresponding TF-A LTS
155 itself to be ported to LTS. However, decision-making about those patches need
160 CI Scripts moves forward with TF-A changes, since we need to checkout the
163 Though we are unlikely to update CI scripts, but time to time migrating a newer
164 FVP version or deprecating certain tests due to unavailability of platforms may
165 influence updates to CI Scripts.
169 Both Hafnium and OP-TEE move forward with TF-A changes so we need to freeze their
174 Updates to the version of MbedTLS used with LTS will happen time to time based on
175 maintainers call to update them or not.
186 it would make sense to leave at least a month after the November release and
188 is December which tends to be slower due to holidays. So, an end-of-November
192 Going forward we should strive to make the period smaller and smaller until
194 and CI/CD infra is good enough to allow that to happen.
212   LTS criteria, they are backported to LTS 2.8.0 which results in LTS 2.8.1
215   isn’t as much to test and debug as an annual LTS release has. Also companies
216   might want to deploy critical patches soon.
223 be TFTF LTS 2.8.0 in Feb 2023, 2.8.1 (if new TFTF tests need to be added for
231 #. Maintainers shall be impartial and strive to work for the benefit of
233 #. Objective and well-defined merge criteria to avoid confusion and discussions
235 #. The maintainers shall explain the lifecycle of a patch to the community,
239 #. Constantly refine the merge criteria to include more partner use cases
240 #. Ensure that all candidate patches flow from the main branch to all LTS branches
255 This section documents the daily tasks that a maintainer might perform to
257 down steps and does not have to make policy level decisions for merge, testing,
260 #. Monitor the main branch to identify candidate patches for the LTS branches
261 #. Monitor emails from LTS triage report to choose patches that should be
263 #. Cherry-pick agreed patches to LTS branches co-ordinate review process and Monitor
266 #. Propose or solicit patches to the main branch and tag them as candidates for LTS
267 #. Monitor Github dependabot pull requests to identify patches that could be taken for a given LTS
277    lts-2.12, etc.). It contains a list of patches to be cherry-picked into a new
283 #. For the version 2.x for which you want to create a new release, open its CSV
284    file. For each patch listed, **from the bottom to the top**, run ``git
286 #. Some of the patches of this list may not be taken, mainly due to false
289 #. Some dependency patches, not listed in the CSV file, may have to be taken, to ease the
292    (This has to be done only once).
294 #. Cherry-pick the dependabot patches dedicated to the given LTS. Those patches should be amended
295    to add a gerrit Change ID.
301    cherry-picked patch/patch-stack is pushed to the corresponding branch. If
302    this CI run passes, it automatically applies the Verified+1 (V+1) label to
311    dedicated scripts for each LTS version which have to be updated manually. This is the case
313    will be cherry-picked from master branch to the LTS branch the same way it is done for TF-A.
314    There is no automation for those repositories. So the patches will have to be merged manually,
315    and for tf-a-ci-scripts and tf-a-tests, tags will also have to be set manually.
319 This section lists the steps needed to put the LTS system in place. However,
320 to kick start LTS in Nov ‘22, only a few steps are needed. The rest can follow
326 The following steps are necessary to kickstart the project and potentially
331 #. Request all platform-owners to test and debug the RC branch
338 Above will buy us time to then work on the rest of the execution plan which
342 #. The maintainers shall publish the well-defined merge criteria to allow
343    the community to choose candidate patches
347    a. Tests required to pass in the CI/CD flow
351 #. The maintainers shall publish a mechanism to choose candidate patches for
353 #. The maintainers shall publish a mechanism to report bugs `[1]`_ seen with
361 #. The CI/CD infrastructure shall provide means to
364    b. automatically cherry-pick a patch to a given LTS branch
366    d. gentle ping in LTS discord channel asking for reviews to ensure
372 In our discussions, in addition to the above points we also considered some
375 | Q. What happens when a bug fix applies just to a LTS branch and not to the
383 | A. The maintainers will add more detail to the review and merge process to
392 | Q. What if LTS support duration needs to be extended to longer than 5 years?
396 become real problems, then we will have concrete data and be better able to
398 is not the final one. We will constantly be discussing it and deciding how to
403 [1] The plan is to create a system where reviewers can tag a patch on mainline which
404 gets automatically rebased on LTS and pushed to Gerrit. On seeing this patch,
406 an email to the maintainers announcing the arrival of a candidate patch for the
415 will be merged to the affected LTS branches after completing the review process.