Phriction Trusted Firmware Trusted Firmware-A (TF-A) Long-term support (LTS) proposal History Version 1 vs 2
Version 1 vs 2
Version 1 vs 2
Edits
Edits
- Edit by vwadekar, Version 2
- Oct 7 2020 4:24 PM
- Edit by joannafarley-arm, Version 1
- Oct 7 2020 1:54 PM
Original Change | Next Change » |
Edit Older Version 1... | Edit Older Version 2... |
Content Changes
Content Changes
TBD
//This page is under construction and not ready for public review//
**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 supporting new hardware features. But for platforms in production, it leaves a hole 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 relied on a long term support policy to address this concern. 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 rely on the path chosen by various open source software projects and define a long-term support policy. This proposal will not succeed without the support of the community and relies on contributions from Arm, its partners and platform owners.
**Motivation**
The following are some of the problems faced by a typical vendor when maintaining a software version downstream
# The cost to maintain a software release and keep it updated with important software changes from upstream is too high
# The cost to productize a newly released version is too high
# Lack of pre-defined tests upstream means the code cannot be immediately deployed to the field
# Some aspects like documentation, code analysis reports, long term tool availability are unclear
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.
**Proposal**
The following would be the expectations from a long-term support release branch.
# 100% test coverage with a publicly available report for every changelist
# Well defined policy to detect, report and deploy software fixes for mitigating security issues, stability concerns, erratas and bugs
# 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 for each sub-release
**References**
- Tech forum discussion (https://www.trustedfirmware.org/meetings/tf-a-technical-forum/) on 10 Sep, 2020.
TBD//This page is under construction and not ready for public review//
**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 supporting new hardware features. But for platforms in production, it leaves a hole 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 relied on a long term support policy to address this concern. 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 rely on the path chosen by various open source software projects and define a long-term support policy. This proposal will not succeed without the support of the community and relies on contributions from Arm, its partners and platform owners.
**Motivation**
The following are some of the problems faced by a typical vendor when maintaining a software version downstream
# The cost to maintain a software release and keep it updated with important software changes from upstream is too high
# The cost to productize a newly released version is too high
# Lack of pre-defined tests upstream means the code cannot be immediately deployed to the field
# Some aspects like documentation, code analysis reports, long term tool availability are unclear
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.
**Proposal**
The following would be the expectations from a long-term support release branch.
# 100% test coverage with a publicly available report for every changelist
# Well defined policy to detect, report and deploy software fixes for mitigating security issues, stability concerns, erratas and bugs
# 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 for each sub-release
**References**
- Tech forum discussion (https://www.trustedfirmware.org/meetings/tf-a-technical-forum/) on 10 Sep, 2020.