[ros-users] [Discourse.ros.org] [Autoware] Splitting the Autoware.AI repository and changing the organisation

[Dirk Thomas via Discourse.ros.org]

Some thoughts about the two directions of having a single repository containing all packages as well as having separate repositories for each package come. Each comes with its own pros and cons. (Obviously any in between is also possible - a few repos with a few packages each.)

The main characteristics for a single repo - let's start with the positive:
* :+1: A single issue tracker makes it clear where to create / search for tickets.
* :+1: A single PR is sufficient for any kind of change.
* :+1: All packages should be consistent with each other in every single commit.
* :+1: Making a release requires only a single tag (and in case of ROS a `bloom` invocation).

On the other hand the downsides of a monolithic repo are:
* :-1: Access can't be granted on a granular level - either a contributor has write access to everything or nothing.
* :-1: CI is probably challenging to setup if you don't want to build everything on each pull request even if it only touches a specific subset of the repo.
* :-1: If the amount of issues / pull requests grows with the community having all in one place might be overwhelming.
* :-1: Since releases cover the whole repo (at least with `bloom` in its current form that is) you have to release new version of packages which actually haven't changed in order to ship changes in other packages. 
 
Since naturally the pros of one option are the cons of the other I will only mention different aspects for the separate repository option:

* :+1: Users / developers only fetch the code parts they actually want to modify and get binary releases of other packages which significantly reduces the build time.
* :+1: Naturally your CI will be much more efficient by limiting the testing to the actually affected subset of packages.
* :-1: You will need a way to test changesets which span across repository boundaries. For ROS 2 we commonly run jobs building multiple repos while use the same custom branch in them for related changes.
* :-1: Managing multiple repositories does take more effort. That being said tools like `vcs` and `hub` allow you to manage multiple repositories pretty effectively - from rebasing multiple repos to creating multiple PRs at the same same for separate repos. 


Some real world examples for the different options:
* [ros_comm](https://github.com/ros/ros_comm/): containing 32 packages. Currently the desire is to split this repo up. E.g. looking at the ridiculous releases / changelogs of [some packages](https://github.com/ros/ros_comm/blob/d574389e54d82cdcbe2ddece73e7409e713f9f31/tools/rosmsg/CHANGELOG.rst).
* [colcon](https://github.com/ros/): each repo containing only a single Python package. While certainly on the extreme side it nicely helps enforcing modularity and each package has its own release cycle and can follow semver without being affected by unrelated code.
* The ROS 2 repositories fall somewhere into the middle between these two extreme options.
  * Some packages are tightly coupled and therefore grouped into a single repo to avoid the cons of separate repos and since they are versioned / released together.
  * Separate subsystems are still separated into different repositories. E.g. the command line tools in `ros2cli` don't have to be in the same repo as the simulation related packages. In these cases the goal to develop / maintain / release them individually (and grant different people access) was weighted more important.
  * This approach also makes it easier to accept new packages and still put them under the "official" `ros2` org unit without having to integrate them into a monolithic repository (which would increase the effort for building / testing / CI / maintenance continuously).


Clear one approach doesn't fit everyone's needs. So good luck finding the right balance for your use case.





---
[Visit Topic](https://discourse.ros.org/t/splitting-the-autoware-ai-repository-and-changing-the-organisation/8139/30) or reply to this email to respond.