Hi Okash/Varun/all
Thanks for this. Some comments from me:
* Criteria: I agree with Joakim that in some cases, a feature may need to be backported as a dependency, although I think this can be mainly decided by the LTS maintainer(s) on a case by case basis. TSC should only be needed where there's controversy/disagreement. There's no mention of normal (i.e. non-security) bugs in generic code. Presumably these don't meet the criteria (?), but it's better to be explicit.
* Frequency: Yearly in November makes sense but if they live for 5/7 years that obviously means 5/7 concurrent branches to maintain, which will make automation even more important.
* Regarding automation, clearly all the CI needs to be automated from the start. It may be possible to manually backport to start with but even this will need to be mostly automated if there are many concurrent branches. I know with the Linux LTS branches that patches are tagged for backporting in the mainline commit messages, and scripts automatically backport to the LTS branches. When patches fail to cleanly backport, it's up to the LTS community to address as it's not scalable for the LTS maintainer(s) to fix all problems. We could consider copying this model (even the scripts) eventually. You mention tagging patches on mainline instead, which could work but I guess could result in tag proliferation.
* Testing criteria: +1 on Joakim's comment about downstream testing not gating LTS patch merging. I’d also say that platforms can only be tested in the LTS CI if they are also tested in the mainline CI.
* Test-and-debug period: "it is expected that more testing and debugging will be done on the November release of TF-A". The testing criteria in the previous section suggest LTS tests are a subset of mainline testing, so in theory the LTS release could be made at the same time as main release. I guess you mean there needs to be more downstream testing of the mainline release before the first LTS release is made. That's fine but this should be made clear and there should be a fixed window so that downstream testing doesn't gate the LTS release.
* "[LTS Maintainer to] Monitor the main branch to identify candidate patches for the LTS branches". This might work to start with but I don't think is very scalable. I think it's reasonable to make all TF-A contributors responsible for identifying such patches at the time they created, with the LTS maintainer acting as backup when things are missed.
* "After reviews are complete, merge the patch and bump the minor version, if required". This suggest no downstream testing is required for minor LTS versions - is that right? I would have thought a small window is required. Or can we assume that further patches/releases are made if there are problems?
* "What happens when a bug fix applies just to a LTS branch and not to the master branch?". If a bug is only reproducible on the LTS branch, then it seems to me this is a reasonable exception to the "only backport from mainline" rule.
* "When testing a backported patch, what if one of the partners needs more time while the patch fix is time-critical and hence slowing other partners?". I would say there should be a fixed window. If a partner subsequently finds a problem, another minor release can be made.
* I suspect a new TF-A LTS mailing list will be required for this (TBD).
* Maintainership options: This is going to take more discussion, but my personal view is the current set of maintainers/contributors does not closely intersect with those interested in consuming an LTS, so it's wouldn't be fair for the current maintainers/contributors to take the whole burden of LTS maintainership.
Regards
Dan.
-----Original Message----- From: Okash Khawaja via TSC tsc@lists.trustedfirmware.org Sent: 08 August 2022 18:49 To: tf-a@lists.trustedfirmware.org Cc: tsc@lists.trustedfirmware.org; Varun Wadekar vwadekar@nvidia.com Subject: [TF-TSC] Finally, a TF-A LTS Proposal!
TL;DR: Attached is the TF-A LTS proposal doc. Please review and share your thoughts.
Hello everyone,
Long term support for TF-A has a long history. As a community we have flirted with it for a while, and like any flirtation, it started with gossip -- in our case, over mailing list [1] -- more than two years ago. Then Varun Wadekar did a wonderful tech forum presentation [2] which demonstrated interest in the topic and raised interesting questions about LTS.
After some time, the affair lost headline status, only to be revived again [3], earlier this year. This time however, there is a formal proposal (no pun intended). After the mailing list discussion and feedback from TF-A tech forum [4], we have put together a draft which attempts to give a concrete idea about what the TF-A LTS will look like.
Please spare some time to read through it and share your feedback. The plan is to put LTS into action this November.
Cheers! Okash
[1] https://lists.trustedfirmware.org/archives/search?mlist=tf- a%40lists.trustedfirmware.org&q=%5BTF-A%5D+ATF+LTS+version [2] https://www.trustedfirmware.org/docs/TF-A-LTS.pdf [3] https://lists.trustedfirmware.org/archives/list/tf- a@lists.trustedfirmware.org/thread/ZZ2DDIW2DS4B7QYHYOL7XE4IPUW7LUNT/ [4] https://www.trustedfirmware.org/docs/TForg_LTS_proposal.pdf