This is the running minutes and actions for TF-A LTS **Date**: tbd **Attendees**: **Minutes**: - List Item ------------------------------------------- **Date**: Oct 18, 2022 **Attendees**: Okash Khawaja (NVIDIA), Varun Wadekar (Google), Bipin Ravi (arm), Joanna Farley (arm), Doug Richmond (arm) **Minutes**: # LTS Branch will be created after the V2.8 release at the end of November. # Must also branch TFTF and the CI. # Target for the formal release version of the LTS branch will be at the beginning of February actual date TBD. # Partner testing will be performed on the LTS candidate on their downstream platforms during December and January to ensure that the LTS branch is considered stable. This is supposed to cover the extended regressions on platforms outside of TF-A. During this time the LTS should be labeled as an RC version until conclusion of testing and agreement that the formal first LTS release can be approved and published. # Only Bugs and fixes approved by the maintainers should be approved to be included in the LTS up to the point of its first version. # The versioning scheme needs to be defined. The first release in February could be versioned as lts-2.8.1 but needs agreement that this versioning does not have the potential of causing confusion with any consumers. # Any fixes to the LTS will only be fixes to the published functionality within either common or platform code. If there are corner cases / exceptions to this policy, then it will be the responsibility of the maintainers to decide if the code is merged from TF-A main to the LTS branch. # All changes required by the LTS will be tested and merged to TF-A main before being considered for inclusion in the LTS. Any exception to this requirement needs to be further thought about and discussed. # A mailing list needs to be created for the LTS branch with all LTS interested partners and maintainers to ensure good communication for the branch status. # Errata and other fixes required by the LTS from TF-A main will need to be identified, tested, approved by maintainers, and merged into the LTS. This process needs to be made as efficient as possible to reduce the effort required. # To allow this process to be made efficient scripts will need to be developed to highlight changes (security fixes, bugs or errata) to cherry pick the changes from TF-A Main and trigger CI tests (post commit hook to auto merge into another branch and kick off runs) and automatically email the maintainers for their manual approval prior to automatic merging to the LTS. # The manual approval is to maintain the quality of the LTS in case of patches not being correctly identified by entry of keywords for inclusion in the LTS branch. # This design requires more discussion, and a follow up design is to be created with detail for the scripts which will need development prior to the LTS being published. # Resource for the script development needs to be named. There is currently no development resource to perform this work. # Where does the script run? 11. Errata for all CPUs needs to be included in the LTS branch. If a new partner was to start using the LTS for resident LTS CPUs, it could cause significant effort to add all the applicable errata if they were not present in the first place. Only adding critical errata for CPUs being used for current interested partners using the LTS on platforms could cause other issues with the branch configuration quality. 12. The LTS life span is understood to be 5 years (with interest to extend up to 7 years which needs further thoughts) and all LTS participating partners and arm are committed to provide maintainer support for this period. Arm has stated their named resource for Year 1 and subsequent years are to be confirmed after this pilot period.

This is the running minutes and actions for TF-A LTS **Date**: tbd **Attendees**: **Minutes**: - List Item ------------------------------------------- **Date**: Oct 18, 2022 **Attendees**: Okash Khawaja (NVIDIA), Varun Wadekar (Google), Bipin Ravi (arm), Joanna Farley (arm), Doug Richmond (arm) **Minutes**: # LTS Branch will be created after the V2.8 release at the end of November. # Must also branch TFTF and the CI. # Target for the formal release version of the LTS branch will be at the beginning of February actual date TBD. # Partner testing will be performed on the LTS candidate on their downstream platforms during December and January to ensure that the LTS branch is considered stable. This is supposed to cover the extended regressions on platforms outside of TF-A. During this time the LTS should be labeled as an RC version until conclusion of testing and agreement that the formal first LTS release can be approved and published. # Only Bugs and fixes approved by the maintainers should be approved to be included in the LTS up to the point of its first version. # The versioning scheme needs to be defined. The first release in February could be versioned as lts-2.8.1 but needs agreement that this versioning does not have the potential of causing confusion with any consumers. # Any fixes to the LTS will only be fixes to the published functionality within either common or platform code. If there are corner cases / exceptions to this policy, then it will be the responsibility of the maintainers to decide if the code is merged from TF-A main to the LTS branch. # All changes required by the LTS will be tested and merged to TF-A main before being considered for inclusion in the LTS. Any exception to this requirement needs to be further thought about and discussed. # A mailing list needs to be created for the LTS branch with all LTS interested partners and maintainers to ensure good communication for the branch status. # Errata and other fixes required by the LTS from TF-A main will need to be identified, tested, approved by maintainers, and merged into the LTS. This process needs to be made as efficient as possible to reduce the effort required. ## To allow this process to be made efficient scripts will need to be developed to highlight changes (security fixes, bugs or errata) to cherry pick the changes from TF-A Main and trigger CI tests (post commit hook to auto merge into another branch and kick off runs) and automatically email the maintainers for their manual approval prior to automatic merging to the LTS. # The manual approval is to maintain the quality of the LTS in case of patches not being correctly identified by entry of keywords for inclusion in the LTS branch. # This design requires more discussion, and a follow up design is to be created with detail for the scripts which will need development prior to the LTS being published. # Resource for the script development needs to be named. There is currently no development resource to perform this work. # Where does the script run? 11. Errata for all CPUs needs to be included in the LTS branch. If a new partner was to start using the LTS for resident LTS CPUs, it could cause significant effort to add all the applicable errata if they were not present in the first place. Only adding critical errata for CPUs being used for current interested partners using the LTS on platforms could cause other issues with the branch configuration quality. 12. The LTS life span is understood to be 5 years (with interest to extend up to 7 years which needs further thoughts) and all LTS participating partners and arm are committed to provide maintainer support for this period. Arm has stated their named resource for Year 1 and subsequent years are to be confirmed after this pilot period.

This is the running minutes and actions for TF-A LTS **Date**: tbd **Attendees**: **Minutes**: - List Item ------------------------------------------- **Date**: Oct 18, 2022 **Attendees**: Okash Khawaja (NVIDIA), Varun Wadekar (Google), Bipin Ravi (arm), Joanna Farley (arm), Doug Richmond (arm) **Minutes**: # LTS Branch will be created after the V2.8 release at the end of November. # Must also branch TFTF and the CI. # Target for the formal release version of the LTS branch will be at the beginning of February actual date TBD. # Partner testing will be performed on the LTS candidate on their downstream platforms during December and January to ensure that the LTS branch is considered stable. This is supposed to cover the extended regressions on platforms outside of TF-A. During this time the LTS should be labeled as an RC version until conclusion of testing and agreement that the formal first LTS release can be approved and published. # Only Bugs and fixes approved by the maintainers should be approved to be included in the LTS up to the point of its first version. # The versioning scheme needs to be defined. The first release in February could be versioned as lts-2.8.1 but needs agreement that this versioning does not have the potential of causing confusion with any consumers. # Any fixes to the LTS will only be fixes to the published functionality within either common or platform code. If there are corner cases / exceptions to this policy, then it will be the responsibility of the maintainers to decide if the code is merged from TF-A main to the LTS branch. # All changes required by the LTS will be tested and merged to TF-A main before being considered for inclusion in the LTS. Any exception to this requirement needs to be further thought about and discussed. # A mailing list needs to be created for the LTS branch with all LTS interested partners and maintainers to ensure good communication for the branch status. # Errata and other fixes required by the LTS from TF-A main will need to be identified, tested, approved by maintainers, and merged into the LTS. This process needs to be made as efficient as possible to reduce the effort required. ## To allow this process to be made efficient scripts will need to be developed to highlight changes (security fixes, bugs or errata) to cherry pick the changes from TF-A Main and and trigger CI tests (post commit hook to auto merge into another branch and kick off runs) and automatically email the maintainers for their manual approval prior to automatic merging to the LTS. # The manual approval is to maintain the quality of the LTS in case of patches not being correctly identified by entry of keywords for inclusion in the LTS branch. # This design requires more discussion, and a follow up design is to be created with detail for the scripts which will need development prior to the LTS being published. # Resource for the script development needs to be named. There is currently no development resource to perform this work. # Where does the script run? 11. Errata for all CPUs needs to be included in the LTS branch. If a new partner was to start using the LTS for resident LTS CPUs, it could cause significant effort to add all the applicable errata if they were not present in the first place. Only adding critical errata for CPUs being used for current interested partners using the LTS on platforms could cause other issues with the branch configuration quality. 12. The LTS life span is understood to be 5 years (with interest to extend up to 7 years which needs further thoughts) and all LTS participating partners and arm are committed to provide maintainer support for this period. Arm has stated their named resource for Year 1 and subsequent years are to be confirmed after this pilot period.