Hi Joakim,
On 4/2/20 10:18 AM, Joakim Bech via TF-A wrote:
Hi Sandrine,
On Wed, Apr 01, 2020 at 11:46:20AM +0200, Sandrine Bailleux wrote:
Hi Joakim,
On 4/1/20 10:08 AM, Joakim Bech via TSC wrote:
How that works in practice is that all OP-TEE maintainers are adding their "Tested-by" (see example [2]) tag for the platform they maintain when we're doing a release. If there are platforms with no "Tested-by" tag, then they simply end up with the "last known version".
I think that's a very good idea!
The "Tested-by" part for OP-TEE releases has been working pretty good, not sure how scalable it is the long run though. To give some more info regarding the "last known version", we even at one point had some stop-light for that. I.e. if a maintainer missed testing a release once, then it became "orange". If missed twice, then it became "red" and we showed last know supported version. But we dropped that idea a short while after introducing it.
May I know why you dropped the idea? Was it too much maintenance? If that's the reason I guess again this could be addressed with some automation work (generating the stop-light status from the commit message info).
However, to keep that up-to-date, it requires some discipline from the people maintaining such a table ... something that we in the OP-TEE project haven't been very good at :)
Can't this be automated, such that it doesn't need to be manually kept up-to-date? I imagine we could have some tools generating the platform support table out of such a commit message.
Indeed it could, it's just a matter of doing some scripting if one doesn't want to do it manually. I already have Python scripts pulling all tags from GitHub pull requests. But there are of course several other ways how one could pull that kind of information.
Regards, Sandrine
Hi Sandrine,
On Tue, Apr 07, 2020 at 03:04:13PM +0200, Sandrine Bailleux wrote:
Hi Joakim,
On 4/2/20 10:18 AM, Joakim Bech via TF-A wrote:
Hi Sandrine,
On Wed, Apr 01, 2020 at 11:46:20AM +0200, Sandrine Bailleux wrote:
Hi Joakim,
On 4/1/20 10:08 AM, Joakim Bech via TSC wrote:
How that works in practice is that all OP-TEE maintainers are adding their "Tested-by" (see example [2]) tag for the platform they maintain when we're doing a release. If there are platforms with no "Tested-by" tag, then they simply end up with the "last known version".
I think that's a very good idea!
The "Tested-by" part for OP-TEE releases has been working pretty good, not sure how scalable it is the long run though. To give some more info regarding the "last known version", we even at one point had some stop-light for that. I.e. if a maintainer missed testing a release once, then it became "orange". If missed twice, then it became "red" and we showed last know supported version. But we dropped that idea a short while after introducing it.
May I know why you dropped the idea? Was it too much maintenance? If that's the reason I guess again this could be addressed with some automation work (generating the stop-light status from the commit message info).
Yes, mainly too many manual steps. I'm sure it could be automated in one or another way.
However, to keep that up-to-date, it requires some discipline from the people maintaining such a table ... something that we in the OP-TEE project haven't been very good at :)
Can't this be automated, such that it doesn't need to be manually kept up-to-date? I imagine we could have some tools generating the platform support table out of such a commit message.
Indeed it could, it's just a matter of doing some scripting if one doesn't want to do it manually. I already have Python scripts pulling all tags from GitHub pull requests. But there are of course several other ways how one could pull that kind of information.
Regards, Sandrine
tf-m@lists.trustedfirmware.org
-
Joakim Bech -
Sandrine Bailleux