Following up on #295 , which added zephyr/module.yml (and zephyr/README.md) so that CMSIS_6 can be consumed directly as a Zephyr module.
I wanted to understand the reasoning a bit better. Zephyr already maintains its own fork of upstream repos for module integration (as it did previously with CMSIS 5 via zephyrproject-rtos/cmsis). Given that a fork can pull/rebase from ARM-software/CMSIS_6 on a schedule, and that adding the module descriptor as a Zephyr-side patch on top of that fork seems like a fairly small, automatable maintenance task — what was the deciding factor for carrying this metadata in the canonical upstream tree instead?
A few things I'd be curious about:
- Was the concern specifically about merge/rebase conflicts on a Zephyr-only file every time the fork syncs, or something else (e.g. keeping the fork a byte-for-byte mirror for provenance/verification reasons)?
- Does CMSIS_6 have a general policy on accepting similar integration metadata for other downstream build systems (e.g. other RTOSes or build tools that might want the same accommodation), or was this a one-off exception for Zephyr specifically?
- Is there a risk of this becoming a maintenance burden if multiple downstream consumers each want their own adapter directory added upstream?
Not objecting to the change itself — zephyr/module.yml is minimal and clearly scoped, per the PR discussion. Just interested in the policy/precedent behind taking on this kind of downstream-specific file in the canonical repo.
Following up on #295 , which added zephyr/module.yml (and zephyr/README.md) so that CMSIS_6 can be consumed directly as a Zephyr module.
I wanted to understand the reasoning a bit better. Zephyr already maintains its own fork of upstream repos for module integration (as it did previously with CMSIS 5 via zephyrproject-rtos/cmsis). Given that a fork can pull/rebase from ARM-software/CMSIS_6 on a schedule, and that adding the module descriptor as a Zephyr-side patch on top of that fork seems like a fairly small, automatable maintenance task — what was the deciding factor for carrying this metadata in the canonical upstream tree instead?
A few things I'd be curious about:
Not objecting to the change itself — zephyr/module.yml is minimal and clearly scoped, per the PR discussion. Just interested in the policy/precedent behind taking on this kind of downstream-specific file in the canonical repo.