Note: I do not really understand what benefit will splitting and re-organizing of Autoware.AI repo have. Since the plan is to transform it into a sandbox in 12-18 months from now, I really do not think that we spend our resources here very wisely.
However since this topic will also be applicable for Autoware.Auto and since at Apex we have 220 packages in a monolithic repository and everybody loves it - I will provide an input.
You also need:
What I suggest is to have above as subfolders inside the
autoware root folder of a monolithic repo.
@sgermanserrano I do not fully understand how are a repository structure and where you install/run Autoware nodes connected? As it is mentioned further down, you can easily create binaries for just subparts of the repo (e.g. visualization) and install it on the same or different machine than e.g. real-time nodes.
Do we really plan to write our own visualization code and not use e.g. rviz, xviz, rqt_plot, etc.? With that all that we would need to save are visualization config files.
This is a) certainly not applicable to Autoware.AI and b) whether a package is safety-critical or not could also be asserted via a cmake macro and depending on that you can build which CI rules and checks apply to that particular package or not.
@amc-nu all of your requests can be done in one repo. I claim that it is actually even easier to design and define cleaner and minimal interfaces. For testing that no intended dependencies creep over
colcon build builds the packages in an isolated mode.
I would also add:
- you do not need a feature and code freeze when doing releases, these can both be one
- single entry point for developer, all work for developers is in one place
- much easier to co-host documentation and code in one repo and actually make checks against changed code (e.g. changed executable names, APIs, …)
- much better traceability from feature request, design document, code, tests, PR and CI. E.g. OSRF folks have to manually link github issues with PRs and PRs with CI/CD, e.g. https://github.com/ros2/rclcpp/pull/639#issuecomment-470160609. Here I am not 100% certain if this just a gitlab feature but in gitlab in the monolithic repo this happens automatically
- easier to extract activity report (commits, branch graph, analytics, …)
- easier user/organization management
I think that all 3 above points can be addressed:
- if you split packages as proposed above you can modules independently and then re-use artifacts from previous builds => we are doing this
- amount of issues/PRS can be mitigated by someone like you @gbiggs
- as @davetcoleman mentioned this is a limitation of bloom
We are more than happy to share what we developed for our internal mono repo in terms of layout and CI.