Sandrine,
Really glad to see this being pulled together. A couple of areas of feedback around the Platform Support Life Cycle.
As previously mentioned there are two orthogonal concerns captured in the current life cycle: Support and Functionality. I'd like to see these split out. For functionality, chip vendors may not have a business case for supporting all features on a given platform but they may provide full support for the features they have chosen to include. A simple example would be supporting PSA FF Isolation Level 1 only due to lack of HW isolation support needed to achieve Isolation Level 2 or greater.
Also, I'd like to see a stronger standard put forth for platform documentation. If a platform is "supported," I believe the documentation should be complete and accurate. A lack of complete and clear documentation leaves open a wide door for misuse/misconfiguration which could result in a vulnerable system.
Here is a more concrete proposal:
Functional Support: Each project shall provide a standard feature or functionality list. Each platform shall include in its documentation a copy of this list with the supported functionality marked as supported. The platform documentation may reference a ticket if support is planned but not yet present. The platform documentation shall explicitly state if a feature or function has no plans for support.
The feature/functionality list shall be versioned, with the version tied to the release version(s) of the project. In this way, it will be clear if a platform was last officially updated for version X but the project is currently at version Y > X. Note: projects will need to adopt (if they have not already) a version scheme that distinguishes between feature updates and bug fixes.
Each project and platform shall use tags or similar functionality on tickets to associate tickets to features/functionality and platforms. If the names of tags can't match the name of the feature or platform exactly then a mapping shall be provided in the appropriate document(s).
Life Cycle State
Fully Supported There is (at least) one active code owner for this platform. All supported features build and either all tests pass or failures are associated with tracked known issues. Other (not associated to a test) Known Issues are tracked Documentation is up to date
Note: Projects should document standards on how "active" code ownership is measured and further document standards on how code owners are warned about impending life cycle state changes.
Orphan There is no active code owner All supported features build and either all tests pass or failures are associated with tracked known issues. Other (not associated to a test) Known Issues may not have been maintained (as there is no active code owner) Documentation status is unclear since there is no active code owner. There has been no change to the feature/functionality list in the project since the platform was last "Fully Supported"
Out of date Same as orphan, but either: there have been changes to the feature/functionality list, or there are failing tests without tracked tickets, or there are known documentation issues.
Deprecated Same as Out of Date, but the build is broken. Platform may be removed from the project codebase in the future.
Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development)
-----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Sandrine Bailleux via TF-M Sent: Tuesday, March 24, 2020 4:42 AM To: tf-a; tf-m@lists.trustedfirmware.org; tsc@lists.trustedfirmware.org; op-tee@linaro.org Cc: nd@arm.com Subject: [EXTERNAL] [TF-M] Project Maintenance Proposal for tf.org Projects
Hello all,
As the developers community at trustedfirmware.org is growing, there is an increasing need to have work processes that are clearly documented, feel smooth and scale well. We think that there is an opportunity to improve the way the trustedfirmware.org projects are managed today.
That's why we are sharing a project maintenance proposal, focusing on the TF-A and TF-M projects initially. The aim of this document is to propose a set of rules, guidelines and processes to try and improve the way we work together as a community today.
Note that this is an early draft at this stage. This is put up for further discussion within the trustedfirmware.org community. Nothing is set in stone yet and it is expected to go under change as feedback from the community is incorporated.
Please find the initial proposal here:
https://developer.trustedfirmware.org/w/collaboration/project-maintenance-pr...
Please provide any feedback you may have by replying to this email thread, keeping all 4 mailing lists in the recipients list.
I will collate comments from the community and try to incorporate them in the document, keeping you updated on changes made between revisions.
Regards, Sandrine