Open krystian-hebel opened 3 months ago
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.
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.