Pin Zephyr dependencies to dedicated commit

[martinjaeger]

Use case

The west.yaml points to the staging branch of the forked Zephyr repository.

It is usually good practice to specify a dedicated commit or the version branch of a dedicated Zephyr version (e.g. v4.2-branch) in order to make sure builds are reproducible and we don't suddenly get breaking changes when this repo and the staging branch diverge.

I guess a fixed commit would have avoided the issues I ran into in PR #79.

Describe the solution you'd like

Change the west.yaml e.g. like this:

  projects:
    - name: zephyr
      revision: v4.2-branch

[kr-t]

Hi, the reason we have it, that we can add other zephyr-relevant features easily, that we might need. For example, we added the PSRAM support which is not yet in zephyr - this way we can have benefits of having a lot of RAM for WAMR apps. We plan update the branch from 4.2 time to time. But since the commits are tested and fixed - not having random updates makes the project safter in my opinion (missing smf updates is on me ofc, that should have been done while we ported to 4.2).

[kr-t]

on more thing: each update on zephyr's staging shall be tested thoughtfully, so it doesn't break anything. The idea was always that it's updated not very often, and when merge from zephyr's upstream is done, then tested thoughtfully.

I'd say what we want to do instead, is to find better build-test mechanism: as we can see my compiler catch no issues, while yours had stopped the build process.

[martinjaeger]

You can still point to your forked v4.2-branch with cherry-picked updates. But it should be clear which Zephyr version a specific version of Ocre is using. To me this is not clear if the branch the west.yml points to is named staging. And once you add more commits to staging, Ocre might suddenly break.

Ideally, you would use a specific commit hash instead of a branch. This is the only way to make sure that builds are always consistent and don't break.

Of course, each Zephyr update should be tested thoughtfully.

[kr-t]

I agree with you that adding more clarity would be very beneficial, as well as having better namings. I will think about renaming the staging branch into something more appropriate or to have some tags clearly showing, that we use 4.2's version and a specific hash. Let's keep this issue open as long as we don't have aforementioned fixes and clarities delivered.