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

Dave Coleman via Discourse.ros.org ros.discourse at gmail.com
Fri Mar 8 04:46:29 UTC 2019

Sure, I'll give my two cents!

I've loved the merging of MoveIt code into few repos, and I'd really like to merge more. I think a great example of a single-repo ROS project is the new [navigation2](https://github.com/ros-planning/navigation2/) project - its way more consolidated than MoveIt is. 

* The source code is buried several layers down a deep directory hierarchy.

By splitting repositories, you're going to reduce the directory hierarchy by likely just one level. Is this really worth it? Software projects get complex, but its not the repo layout that makes it easier.

* New contributors are confronted with a huge amount of code, which discourages them from diving
in to make a bug fix. Not knowing where to put a package or algorithm they want to contribute is
also a symptom.

I really don't see how separating the code across the internet (different github repos) makes finding code easier for new contributors. I'd argue its the opposite. 

* Doing CI for a single change in a single file, no matter how small, requires that the CI pipeline
build all of Autoware. This currently takes anywhere from an hour and a half up.

Even with split up repositories you probably should test it against the other repos every time also, to ensure the whole system builds. Otherwise you're going to have to test it against the debians last time they were synced, which is every ~3 months? This means you can't change the API of repos with each other because one of the other repos will always be out of sync.

There are lots of other clever ways to have CI only test relevant parts of the system, but this requires more coding. One very simple improvement is to skip all of CI everytime the change list is only documentation (for example .md files)

* It is essentially impossible to version different parts of Autoware independently.

This is a limitation of the bloom-release tools, not of single git repos. If you manually released debians the way most other Ubuntu packages do, this limitation wouldn't exist. 

Also, do you really need different versions of software within the Autoware project? Isn't it one large software project?

* It is difficult to guarantee a separation between safety-critical and non-safety-critical code.

I don't see how this difficulty really goes away with separate repos. Someone could still put unsafe code in the wrong places in either scenarios. Its always up to your PR reviewers to enforce this.

Side note: I have used some pretty cool Bazel rules to restrict access to certain parts of a code base from other parts.

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

More information about the ros-users mailing list