dasharo-issues
dasharo-issues copied to clipboard
Create a table of platforms supported by given branch
Dasharo version (if applicable) All
Dasharo variant (if applicable) All
Affected component(s) or functionality (if applicable)
Documentation
Brief summary
We support many different platforms. Some of them use bleeding-edge dasharo branch, while others are stuck on older branches like e.g. dasharo-4.21. Currently, we don't have a clear way of mapping platforms to their respective branches, other than checking release notes for each platform. A list of such mapping would make it easier to spot potential consequences of modifying common code, limiting the amount of testing required.
It would also help with estimating amount of work (time, money) required to add support for a specific feature, which sometimes could require either rebasing to fresher code or backporting. That would allow better informed decisions when client asks for feature cost.
Taking this one step further, we could remove files from coreboot configs directory for platforms not supported by given branch. This would make it harder to inadvertently build image from wrong code base, as well as reduce number of changes required when bumping versions of payloads.
Additional context
If we want to allow different payload revisions on one coreboot branch, this would also have to be included in the table. However, this is a maintenance burden that, if possible, should be avoided.
I cheer up this effort. Thanks for raising awareness of the problem. I am especially eager to see some progress in integration costs, which often need to be improved in translation and at least partially because of the way we organize work. To some extent, it is related to https://github.com/Dasharo/dasharo-issues/issues/310
Table added in https://github.com/Dasharo/docs/pull/888. In order to not have it outdated in few days, we must include a requirement for updating that table in the release processes.
https://github.com/Dasharo/dasharo-issues/issues/452 may be a next step after this is done, but as mentioned there, the amount of options would quickly make such table unmaintainable, at least if we want to keep using Markdown for that.
#452 may be a next step after this is done, but as mentioned there, the amount of options would quickly make such table unmaintainable, at least if we want to keep using Markdown for that.
Wouldn't the Test Matrix table which can be found in every platform section serve the purpose of a list of supported functionalities? Only even that table, which can be copied from the test matrix at Gdocs, often shows different tests than are listed as supported on the test matrix on Gdocs. I imagine there could be some kind of mapping defined where the test suites are correlated with some functionalities of Dasharo, which would also need to be defined.
Some configuration file, such as a json file, could be used by a script to automatically create a "supported features" page using the test scope defined in the Tests table in the test matrix:
{
{
"feature": "IPXE Network Boot Menu support",
"description": "Some more verbose description of the feature which will be shown on the features list page"
"test_cases": {
"PXE*"
}
},
{
"feature": "S0ix Sleep",
"description": "something, something"
"test_cases": {
"SMS001.001",
"SUSP005.002"
}
},
...
}|
Such file could be a burden to maintain though.
Table of platforms vs branches is here: https://docs.dasharo.com/variants/versions/
Table of platforms vs branches is here: https://docs.dasharo.com/variants/versions/
Do you know if this is updated automatically? The last update was 2 months ago and we had some releases meanwhile:
docs/variants/protectli_vp2430/releases.md:## v0.9.0 - 2025-05-13
docs/variants/novacustom_v540tu/releases_heads.md:## v0.9.0 - 2025-03-20
docs/variants/qemu_q35/releases.md:## v0.2.1 - 2025-05-30