Hello @dsankel, thank you for looking into that and sorry for obfuscating the main idea through AI, I had the impression that this would make it better, but anyways… What I want to address with this post is that having a simple starting template project for the Beman project libraries is not enough!
Let’s assume I want to create a new library today and I use the exemplar as a starting template. After a couple of months this template evolved, some new tools and pipelines were introduced, some defaults changed and I want to also include those changes in my library right after I finish the development of the ongoing release.
So, at this point I have to track, check and apply all the changes that happened in the exemplar repo during the period that I developed my library. If this is done manually for one, or maybe a couple of repos it’s fine, but in general it doesn’t scale in a multi-repo approach.
What I propose here is to have a (semi-)automatic mechanism that updates at the end of a development lifecycle the library projects started from the exemplar template. That way the “new staff” from the template will be included in the existing libraries that are still in development, raising the quality standards as time passes and keeping the Beman libraries consistent.
The update should be as non-intrusive as possible and this is why it should be done after a successful release. At this particular moment the library developer has the time to inspect what new tools and pipelines were introduced, fix warnings and investigate potential improvements.
For example, if a new tool like klocwork was introduced in the pipelines (that checks some Misra rules), at the middle of the development, then most probably new warnings will arise, forbidding the release pipeline to run successfully and forcing the developer to solve all the issues before. This will cause frustration to the library developer and he will most probably opt-out and we don’t want that. On the other hand, we don’t want the library developer to only update his library manually, since it is easy to “forget”.
As discussed in this topic Should we have a dedicated repo for infrastructure? - #3 by bretbrownjr, I think that having a core infrastructure repo will decouple the DevOps “staff” needed for the maintenance of all library repos, from the development “staff” needed for a specific library. The infrastructure repo can provide the core DevOps functionality of each library and will get updated at regular intervals as described above, were the exemplar repo will be used as a starting template, but with a twist, the infra repo will be used as a “dependency”.
I don’t want to get into more technical details like if this will be used as a git submodule, downloaded using CMake FetchContent, or as a package, or what are the exact DevOps functionalities that should be provided by the infra repo, or what library specific infrastructure configuration should be, since each one of them might be a different topic by itself.
My vision is to enable developers to use the latest quality standards and tooling without much effort. I hope I made it clear this time what my intention is and what I want to achieve.
Thank you for keeping track with the idea,