Change Details

**LTS Proposal** [[ https://developer.trustedfirmware.org/file/data/yhf5nfsofaqobwja5ss3/PHID-FILE-e2hxgf66tgkg3qzayfyv/TF-A_LTS_Proposal.pdf | https://developer.trustedfirmware.org/file/data/yhf5nfsofaqobwja5ss3/PHID-FILE-e2hxgf66tgkg3qzayfyv/TF-A_LTS_Proposal.pdf ]] **Overview** An important criterion for evaluating and adopting a software platform is support. The Trusted Firmware-A community has been releasing code from the tip every six months. This model works very well for software innovation and implementing new hardware features. But for platforms in production, this policy does not scale in terms of maintenance, backward compatibility of important software fixes, getting latest security mitigations, and overall product lifecycle management. Several open-source software projects (e.g. Ubuntu, Yocto, Linux Kernel) have faced this problem during their lifetime and have implemented a long-term support release as a solution. Long-term support not only extends the period of software maintenance, but also alters the type and frequency of software updates (patches) to reduce the risk, expense, and disruption of software deployment, while promoting the dependability of the software. It does not necessarily imply technical support. Long-term support is needed for commercial reasons too. More specifically, on the device side, when a product is released, the companies must support it such that the number of changes to the firmware are kept to a minimum to avoid the risk of regression. At the same time, the companies don't want to exclude critical patches such as those for security advisories. Similarly on server side, companies want to minimize the churn when deploying fixes during incident response, e.g. due to critical security bugs. This means that those companies must 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 effort. This document proposes a plan to leverage the path chosen by various open-source software projects and define a long-term support release strategy. This proposal will not succeed without the support of the community and relies on their contributions. **Problems** The following are some of the problems slowing down device upgrades. # The investment to maintain a software release and keep it updated with important software changes from upstream is too high. # The cost to productize and deploy a newly released version is too high. # Lack of tests to cover all scenarios means that a new public release cannot be immediately deployed to the field. # Some aspects like documentation, code analysis reports, test reports and long term availability of tools are not available. **Community involvement** The LTS topic was first presented by @vwadekar as a tech forum discussion on 10 Sep, 2020. The LTS topic was [[ https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/thread/ZZ2DDIW2DS4B7QYHYOL7XE4IPUW7LUNT/ | rebooted ]] in the community in May'22. A [[ https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/thread/MT37NYU3PFDLF5F6CRCRJRGD2SMY5BT3/ | proposal ]] was created by @okash and @vwadekar and presented to the community in tech forums on 14 July, 2022 and 8 Sep 2022. The recordings can be found at https://www.trustedfirmware.org/meetings/tf-a-technical-forum/. Thanks to the responses on the mailing list, the proposal has now evolved into the [[ https://developer.trustedfirmware.org/F274534 | attached ]] execution plan. **First LTS branch** The result of the community interest and review of the execution plan from the board, is the introduction of the first LTS release branch. The following sub-sections document the expectations from the branch and the path to the first LTS release. //Expectations// # Stable and well-tested code branch # Well-defined criteria to pick changes for merge # High quality bar for every patch that gets merged # Active support from the maintainers for a minimum of five years # Clear communication of important milestones to the community //Release planning// # The first LTS release will use TF-A v2.8 as the base and be available in Feb 2023. # The branch name will be based on the format: //lts-<base tf-a version>.<rolling minor version>//. e.g. lts-2.8.0 for the first branch. # The branch maintainers plan to introduce a new mailing list (`tfa-lts@lists.trustedfirmware.org`) to engage with the community. We expect the mailing list to be used for announcements, to report issues, to propose changes to cherry-pick, to propose policy changes, to provide feedback, etc. # The release will be scheduled for a Friday and will pick all the patches that were merged in that week. This is a departure from the initial model where we released immediately after a patch was merged. **Call to action** Reviewers are encouraged to review the plan and provide feedback. We request more people to try the LTS release when available and make the project a success. **References** - Tech forum discussion (https://www.trustedfirmware.org/meetings/tf-a-technical-forum/) on 10 Sep, 2020. - Tech forum discussions (https://www.trustedfirmware.org/meetings/tf-a-technical-forum/) on 14 July, 2022 and 8 Sep 2022. - LTS branch creation and execution proposal - https://developer.trustedfirmware.org/F274534

**LTS Proposal** [[ https://developer.trustedfirmware.org/file/data/yhf5nfsofaqobwja5ss3/PHID-FILE-e2hxgf66tgkg3qzayfyv/TF-A_LTS_Proposal.pdf | https://developer.trustedfirmware.org/file/data/yhf5nfsofaqobwja5ss3/PHID-FILE-e2hxgf66tgkg3qzayfyv/TF-A_LTS_Proposal.pdf ]] **Overview** An important criterion for evaluating and adopting a software platform is support. The Trusted Firmware-A community has been releasing code from the tip every six months. This model works very well for software innovation and implementing new hardware features. But for platforms in production, this policy does not scale in terms of maintenance, backward compatibility of important software fixes, getting latest security mitigations, and overall product lifecycle management. Several open-source software projects (e.g. Ubuntu, Yocto, Linux Kernel) have faced this problem during their lifetime and have implemented a long-term support release as a solution. Long-term support not only extends the period of software maintenance, but also alters the type and frequency of software updates (patches) to reduce the risk, expense, and disruption of software deployment, while promoting the dependability of the software. It does not necessarily imply technical support. Long-term support is needed for commercial reasons too. More specifically, on the device side, when a product is released, the companies must support it such that the number of changes to the firmware are kept to a minimum to avoid the risk of regression. At the same time, the companies don't want to exclude critical patches such as those for security advisories. Similarly on server side, companies want to minimize the churn when deploying fixes during incident response, e.g. due to critical security bugs. This means that those companies must 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 effort. This document proposes a plan to leverage the path chosen by various open-source software projects and define a long-term support release strategy. This proposal will not succeed without the support of the community and relies on their contributions. **Problems** The following are some of the problems slowing down device upgrades. # The investment to maintain a software release and keep it updated with important software changes from upstream is too high. # The cost to productize and deploy a newly released version is too high. # Lack of tests to cover all scenarios means that a new public release cannot be immediately deployed to the field. # Some aspects like documentation, code analysis reports, test reports and long term availability of tools are not available. **Community involvement** The LTS topic was first presented by @vwadekar as a tech forum discussion on 10 Sep, 2020. The LTS topic was [[ https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/thread/ZZ2DDIW2DS4B7QYHYOL7XE4IPUW7LUNT/ | rebooted ]] in the community in May'22. A [[ https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/thread/MT37NYU3PFDLF5F6CRCRJRGD2SMY5BT3/ | proposal ]] was created by @okash and @vwadekar and presented to the community in tech forums on 14 July, 2022 and 8 Sep 2022. The recordings can be found at https://www.trustedfirmware.org/meetings/tf-a-technical-forum/. Thanks to the responses on the mailing list, the proposal has now evolved into the [[ https://developer.trustedfirmware.org/F274534 | attached ]] execution plan. **First LTS branch** The result of the community interest and review of the execution plan from the board, is the introduction of the first LTS release branch. The following sub-sections document the expectations from the branch and the path to the first LTS release. //Expectations// # Stable and well-tested code branch # Well-defined criteria to pick changes for merge # High quality bar for every patch that gets merged # Active support from the maintainers for a minimum of five years # Clear communication of important milestones to the community //Release planning// # The first LTS release will use TF-A v2.8 as the base and be available in Feb 2023. # The branch name will be based on the format: //lts-<base tf-a version>.<rolling minor version>//. e.g. lts-2.8.0 for the first branch. # The branch maintainers plan to introduce a new mailing list (`tfa-lts@lists.trustedfirmware.org`) to engage with the community. We expect the mailing list to be used for announcements, to report issues, to propose changes to cherry-pick, to propose policy changes, to provide feedback, etc. # The release will be scheduled for a Friday and will pick all the patches that were merged in that week. This is a departure from the initial model where we released immediately after a patch was merged. **Call to action** Reviewers are encouraged to review the plan and provide feedback. We request more people to try the LTS release when available and make the project a success. **References** - Tech forum discussion (https://www.trustedfirmware.org/meetings/tf-a-technical-forum/) on 10 Sep, 2020. - Tech forum discussions (https://www.trustedfirmware.org/meetings/tf-a-technical-forum/) on 14 July, 2022 and 8 Sep 2022. - LTS branch creation and execution proposal - https://developer.trustedfirmware.org/F274534

**LTS Proposal** [[ https://developer.trustedfirmware.org/file/data/yhf5nfsofaqobwja5ss3/PHID-FILE-e2hxgf66tgkg3qzayfyv/TF-A_LTS_Proposal.pdf | https://developer.trustedfirmware.org/file/data/yhf5nfsofaqobwja5ss3/PHID-FILE-e2hxgf66tgkg3qzayfyv/TF-A_LTS_Proposal.pdf ]] **Overview** An important criterion for evaluating and adopting a software platform is support. The Trusted Firmware-A community has been releasing code from the tip every six months. This model works very well for software innovation and implementing new hardware features. But for platforms in production, this policy does not scale in terms of maintenance, backward compatibility of important software fixes, getting latest security mitigations, and overall product lifecycle management. Several open-source software projects (e.g. Ubuntu, Yocto, Linux Kernel) have faced this problem during their lifetime and have implemented a long-term support release as a solution. Long-term support not only extends the period of software maintenance, but also alters the type and frequency of software updates (patches) to reduce the risk, expense, and disruption of software deployment, while promoting the dependability of the software. It does not necessarily imply technical support. Long-term support is needed for commercial reasons too. More specifically, on the device side, when a product is released, the companies must support it such that the number of changes to the firmware are kept to a minimum to avoid the risk of regression. At the same time, the companies don't want to exclude critical patches such as those for security advisories. Similarly on server side, companies want to minimize the churn when deploying fixes during incident response, e.g. due to critical security bugs. This means that those companies must 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 effort. This document proposes a plan to leverage the path chosen by various open-source software projects and define a long-term support release strategy. This proposal will not succeed without the support of the community and relies on their contributions. **Problems** The following are some of the problems slowing down device upgrades. # The investment to maintain a software release and keep it updated with important software changes from upstream is too high. # The cost to productize and deploy a newly released version is too high. # Lack of tests to cover all scenarios means that a new public release cannot be immediately deployed to the field. # Some aspects like documentation, code analysis reports, test reports and long term availability of tools are not available. **Community involvement** The LTS topic was first presented by @vwadekar as a tech forum discussion on 10 Sep, 2020. The LTS topic was [[ https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/thread/ZZ2DDIW2DS4B7QYHYOL7XE4IPUW7LUNT/ | rebooted ]] in the community in May'22. A [[ https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/thread/MT37NYU3PFDLF5F6CRCRJRGD2SMY5BT3/ | proposal ]] was created by @okash and @vwadekar and presented to the community in tech forums on 14 July, 2022 and 8 Sep 2022. The recordings can be found at https://www.trustedfirmware.org/meetings/tf-a-technical-forum/. Thanks to the responses on the mailing list, the proposal has now evolved into the [[ https://developer.trustedfirmware.org/F274534 | attached ]] execution plan. **First LTS branch** The result of the community interest and review of the execution plan from the board, is the introduction of the first LTS release branch. The following sub-sections document the expectations from the branch and the path to the first LTS release. //Expectations// # Stable and well-tested code branch # Well-defined criteria to pick changes for merge # High quality bar for every patch that gets merged # Active support from the maintainers for a minimum of five years # Clear communication of important milestones to the community //Release planning// # The first LTS release will use TF-A v2.8 as the base and be available in Feb 2023. # The branch name will be based on the format: //lts-<base tf-a version>.<rolling minor version>//. e.g. lts-2.8.0 for the first branch. # The branch maintainers plan to introduce a new mailing list (`tfa-lts@lists.trustedfirmware.org`) to engage with the community. We expect the mailing list to be used for announcements, to report issues, to propose changes to cherry-pick, to propose policy changes, to provide feedback, etc. # The release will be scheduled for a Friday and will pick all the patches that were merged in that week. This is a departure from the initial model where we released immediately after a patch was merged. **Call to action** Reviewers are encouraged to review the plan and provide feedback. We request more people to try the LTS release when available and make the project a success. **References** - Tech forum discussion (https://www.trustedfirmware.org/meetings/tf-a-technical-forum/) on 10 Sep, 2020. - Tech forum discussions (https://www.trustedfirmware.org/meetings/tf-a-technical-forum/) on 14 July, 2022 and 8 Sep 2022. - LTS branch creation and execution proposal - https://developer.trustedfirmware.org/F274534