Change Details

//**This page is under construction**// **Overview** A very 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, 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 extends the period of software maintenance; it 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. 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 contributions from Arm, its partners and platform owners. **Current 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 The technical forum for TF-A on 10 Sep, 2020 was focused on this topic to gauge interest and support from the community. To move the discussion forward, this page intends to capture ideas from the community and eventually crystalize a plan that works for everyone. **Expectations from LTS codebase** There is interest from the community to explore the possibility of a long-term release codebase to solve these problems. The following might be some of the expectations from a long-term support release branch. # Well defined policy to detect, report and deploy software fixes for mitigating security issues, stability concerns, erratas and bugs # 100% test coverage with a publicly available report for every changelist # Up-to-date API reference manual at any given changelist # Well documented performance numbers for important use cases # Usage of Long-term supported toolchains # Well defined policy for accepting new changes # Use of publicly available static analysis tools to improve code quality # Well defined release cadence and key quality indicators **Call to action** Reviewers are encouraged to add to the list of improvement areas and provide expectations from the long-term support release. This will help us define the problem before we start discussing the mechanics of the release. **References** - Tech forum discussion (https://www.trustedfirmware.org/meetings/tf-a-technical-forum/) on 10 Sep, 2020.

//**This page is under construction**// **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, 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 extends the period of software maintenance; it 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. 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 contributions from Arm, its partners and platform owners. **Current 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 The technical forum for TF-A on 10 Sep, 2020 was focused on this topic to gauge interest and support from the community. To move the discussion forward, this page intends to capture ideas from the community and eventually crystalize a plan that works for everyone. **Expectations from LTS codebase** There is interest from the community to explore the possibility of a long-term release codebase to solve these problems. The following might be some of the expectations from a long-term support release branch. # Well defined policy to detect, report and deploy software fixes for mitigating security issues, stability concerns, erratas and bugs # 100% test coverage with a publicly available report for every changelist # Up-to-date API reference manual at any given changelist # Well documented performance numbers for important use cases # Usage of Long-term supported toolchains # Well defined policy for accepting new changes # Use of publicly available static analysis tools to improve code quality # Well defined release cadence and key quality indicators **LTS branches** 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 a tech forum. The recording can be found at https://www.trustedfirmware.org/meetings/tf-a-technical-forum/. Thanks to the response from the community the proposal has now evolved into an execution plan for the first LTS branch. A stake in the ground is to release the first LTS branch in Feb'23. The detailed proposal is attached{F274534}. **Call to action** Reviewers are encouraged to review the proposal 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.

//**This page is under construction**// **Overview** A veryAn 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, 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 extends the period of software maintenance; it 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. 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 contributions from Arm, its partners and platform owners. **Current 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 The technical forum for TF-A on 10 Sep, 2020 was focused on this topic to gauge interest and support from the community. To move the discussion forward, this page intends to capture ideas from the community and eventually crystalize a plan that works for everyone. **Expectations from LTS codebase** There is interest from the community to explore the possibility of a long-term release codebase to solve these problems. The following might be some of the expectations from a long-term support release branch. # Well defined policy to detect, report and deploy software fixes for mitigating security issues, stability concerns, erratas and bugs # 100% test coverage with a publicly available report for every changelist # Up-to-date API reference manual at any given changelist # Well documented performance numbers for important use cases # Usage of Long-term supported toolchains # Well defined policy for accepting new changes # Use of publicly available static analysis tools to improve code quality # Well defined release cadence and key quality indicators **LTS branches** 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 a tech forum. The recording can be found at https://www.trustedfirmware.org/meetings/tf-a-technical-forum/. Thanks to the response from the community the proposal has now evolved into an execution plan for the first LTS branch. A stake in the ground is to release the first LTS branch in Feb'23. The detailed proposal is attached{F274534}. **Call to action** Reviewers are encouraged to add toreview the list of improvement areasproposal and provide expectations from the long-term support releasee feedback. This will help us defineWe request more people to try the problem before we start discussingLTS release when available and make the mechanics of the releaseproject a success. **References** - Tech forum discussion (https://www.trustedfirmware.org/meetings/tf-a-technical-forum/) on 10 Sep, 2020.