Replies: 1 comment 1 reply
-
It's possible that export control / intellectual property review is the real bottleneck. If that's the case then releasing everything as a single unit will just be slowed down to the most difficult-to-review subunit. I think creating a monorepo also has the potential to increase the upstream contribution burden. Users would have to clone that whole repo, and would want to keep application-specific code out of it if they ever want to upstream bug fixes or feature proposals. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello,
I would like to ask my question based on what Jacob wrote in the recent thread about SCH:
I was wondering if you considered a monolithic cFS repository approach where all core and most used apps would be included into one tree?
A clear advantage of a monorepo approach is that all included software shares the same release lifecycle and with some amount of integration tests, the whole tree could be kept consistent in terms of the functionality and the interfaces. The additional benefit, I guess, is that the release management for the cFS team could be simpler this way.
I would be curious to hear what was the idea behind the cFS development team's decision for splitting the core cFS repositories?
P.S. In my understanding, this topic is also connected to another one that I opened before: In-source vs out-of-source use of cFS: Recommended project structure? #319.
Thanks.
Beta Was this translation helpful? Give feedback.
All reactions