docs/about/lts.rst

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
70 b. large parts of the process can be automated
74 #. No features will be backported.
82 #. Patches can only be backported from the master branch. In other words, the
83    master branch will be a superset of all the changes in any LTS branch.
87 This section approaches three questions: for how long should an LTS release be
88 supported, how frequently should LTS releases be made and at which time(s) of
89 the year should the releases be made.
91 1. For how long should an LTS release be supported?
100 2. How frequently should LTS releases be made?
105 3. Which time(s) of the year should the releases be made?
118 To summarize, there will be one LTS release per year. It will be supported for
120 will be based on the November release of TF-A.
141 will be extended to cover testing for LTS as well for boards that are part of
147 branch will need to be regression tested. Since TFTF moves forward with latest
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
156 not be as stringent as for TF-A.
184 Since the LTS branch will be used in product releases, it is expected that more
185 testing and debugging will be done on the November release of TF-A. Therefore
188 is December which tends to be slower due to holidays. So, an end-of-November
190 the LTS branch will be created at the same time as the TF-A November release,
191 but it will be officially released at the end of January or early February.
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
261 #. Monitor emails from LTS triage report to choose patches that should be
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
286 #. Some of the patches of this list may not be taken, mainly due to false
287    positive. If in doubt, that can be discussed either in the “tf-a-lts” channel
289 #. Some dependency patches, not listed in the CSV file, may have to be taken, to ease the
290    application of the LTS patches. This can also be discussed with the other LTS maintainers.
292    (This has to be done only once).
294 #. Cherry-pick the dependabot patches dedicated to the given LTS. Those patches should be amended
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.
341 #. The review criteria for LTS patches must be the same as TF-A patches
377 | A. This will be treated as a special case and the bug, and the fix will be
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
411 [2] Logical will be a patch or patches implementing a certain fix. For example, if a
415 will be merged to the affected LTS branches after completing the review process.