Hi Okash, Varun, all,
On Mon, Aug 08, 2022 at 06:48:42PM +0100, Okash Khawaja via TSC wrote:
> 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.
>
Thanks for putting this together, much appreciated. Some comments from
me/Linaro.
Criteria:
--------
- "large parts of the process can be automated"
I'm not sure I'm fully convinced about that, but if CI/CD/testing have
been configured to have good support for LTS-branches, then the actual
and manual work is mostly doing the actual backporting. Aiming for an
automated process is a good goal.
- "No features will be backported"
As for the criteria I believe your suggestion makes a lot of sense.
Even though I do agree with the "No features will be backported", I'm
pretty sure that from time to time there will be fixes that for some
reason need to pull in features as well, mainly as a dependency. Perhaps
we could change the sentence slightly to indicate that we generally
don't want to backport features, but if a fix depends or is dependant on
a feature, then in some cases we might consider backporting features as
well. Case by case? TF-TSC people could decide?
Lifetime and frequency:
----------------------
I support your suggestions and motivations.
Testing Criteria / 4.Platform tests:
-----------------------------------
Although I support this, I can see foresee that this most likely will be
challenging. I'm talking from my experience as an OP-TEE maintainer. As
the amount of platforms supported grew, it became harder and harder to
get the platform maintainers finding time and helping out with testing
release candidates on their own devices/platforms. We have tried a
couple of different things, like using stop lights in the docs, keeping
tested platforms "green", the ones that hasn't been tested recently
"orange" and the rest "red". However, we abandoned that, since it was a
lot of work to keep track of it. Instead we simply just keep track of
the tested platforms in the git release tag. I.e., we list all platforms
tested both by the core maintainers as well as external platform
maintainers. Sub-optimal, but keeps a track record and keeps things
moving. Here I'm mainly talking about platforms found upstream. In your
suggestion you're talking about platforms that are not maintained
upstream, which in my opinion makes things even more complicated.
In short, I do support something like this, but I think there needs to
be some kind of deadline for downstream testing. If not met, then that
platform shouldn't be considered as up-to-date for a LTS. I think this
is what you also had in mind with "a pre-defined window".
TFTF branching and others gits:
------------------------------
I agree with the need to "LTS tag" TFTF and potentially other projects
as well. I.e., as Joanna indicated, enabling LTS in TF-A might force us
to add LTS branches in the other TF.org gits as well. I've touched upon
it before, but maybe time for putting together TF.org build(s) that
builds (and tests) all projects under the TrustedFirmware umbrella?
Example timeline:
----------------
- "Note that here we don’t allow the extra testing and debugging time
that we had between Nov 2022 and early Feb 2023. This is because there
isn’t as much to test and debug as an annual LTS release has."
I think this is related to my comment further up. If the "large part of
the process can be automated" holds up, then I'd guess that the same
kind of testing could (and should) be done.
Maintainership:
--------------
In short LTS doesn't come for free, so in some way it needs to be
funded. Carving out LTS work from existing work as a maintainer can be
challenging and a lot of maintainers spend time on other "internal"
tasks and use cases as well.
- "A day in the life of a maintainer"
I guess this sections justify my doubts that "large parts of the process
can be automated".
Execution Plan:
--------------
+1
Future plans:
------------
Agree, it's hard to make a bulletproof strategy, but having a strategy
capturing most of the things is a lot better than having no strategy at
all.
Again, thanks for putting together the proposal, it's a good proposal.
> Cheers!
> Okash
>
> [1] https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…
> [2] https://www.trustedfirmware.org/docs/TF-A-LTS.pdf
> [3] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
> [4] https://www.trustedfirmware.org/docs/TForg_LTS_proposal.pdf
> --
> TSC mailing list -- tsc(a)lists.trustedfirmware.org
> To unsubscribe send an email to tsc-leave(a)lists.trustedfirmware.org
// Regards,
Joakim
