Greg Shue

> if three different manifest files each define the same import group, are these shared? This is just another example of a global namespace that must be managed across the...

> broader, for example the arch_ interface which is not application facing needs to be in scope as well, this is being used by OOT architectures for example. There are...

> It is really frustrsating to see this type of discussion always go into modules/mcuboot @nashif It is also really frustrating to see the Zephyr Project not actually support the...

> All this without mentioning forks once! Magic :-) Almost ... "that does not help with zephyr forks" ... "cause branching and forking" This is a present user need, not...

> What makes you think some (good and useful) API change(s) in nrfConnect won't be found in some future upstream Zephyr version? I never thought that. Rather, I thought that...

> OK then why would API changes in nrfConnect not be manageable using the same processes and tools as API changes across upstream Zephyr branches? nrfConnect could use the same...

> And what are those development models you are referring to exactly? Please be specific In the [T2: Star topology, application is the manifest repository](https://docs.zephyrproject.org/latest/develop/west/workspaces.html#west-t2), I am strategically reusing the...

> Be specific: describe something does not work and how it can be fixed. Maintaining support for the topologies cannot depend on any single person being a watchdog on all...

> Solution: > Using Kconfig aliases and obsolete warnings generation using https://www.kernel.org/doc/html/latest/kbuild/kconfig-macro-language.html#built-in-functions $(warning-if,condition,text) function. This works reasonably well for flagging deprecated symbols when users go from one release to the...

> Provide some guarantees, guidelines and a process keeping out of tree users operational Perhaps we need to clearly describe the range of out of tree users we are trying...