The current approach of using a single repository for all of Autoware has become increasingly
untenable as the size of the code has grown. There are several problems with maintaining this
- The source code is buried several layers down a deep directory hierarchy.
- 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.
- 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.
- It is essentially impossible to version different parts of Autoware independently.
- It is difficult to guarantee a separation between safety-critical and non-safety-critical code.
To fix this, one of the major items on the roadmap for 1.12 is to split the repositories and
reorganise the package layout. This will be done as early in the 1.12 iteration as possible, so I’d like to
start discussing it now and come to an agreement on what repositories we will create and what they
Based on discussions with @esteve regarding how to layout the repositories for Autoware.Auto, here
is a starting-point proposal for the new repositories.
Root repository. Contains a README file, the
.reposfile for checking out/installing Autoware
vcs(which will be the preferred method from 1.12), and nothing else.
Core packages related to understanding the world around the car.
Core packages related to planning where the vehicle should go.
Core packages related to controlling the vehicle so that it goes where it should.
Hardware drivers for interacting with hardware, such as the Velodyne driver. Ideally, all
packages in here will be candidates for eventually being pushed upstream somewhere.
Packages that we develop that are not core to Autoware, i.e. you do not need them to drive a
Packages dealing with visualising sensor data, the state of the car, etc.
In addition to the above, we may create additional library-specific repositories for libraries we
create that do not depend on ROS or any functionality from a ROS package. A good example would be
an algorithm for a point cloud processing function. Thanks to the magic of
non-ROS repositories are relatively easy to integrate into a workspace.
Each repository will follow a fairly flat directory structure. Although it is not a rule, as a
guideline I think each repository should be a collection of packages at the same directory level.
This work will be done fairly early in the work for 1.12, because we don’t want to do it while we
have lots of pull requests in flight. I will start another thread soon to discuss the timeline for
the first couple of weeks of the 1.12 work.
Related to splitting the repositories, we are trying to get our hands on the “Autoware”
organisation name. It has been registered by someone else (Shinpei claims it is not him) since
2017, but has not been used since creation. We think that we have a case for getting the name based
on GitHub’s strict anti-name-squatting policy and the activity level in our project. If we are able
to get the name, then we will perform the following actions.
- Rename the CPFL organisation to Autoware.
- Create a new CPFL organisation.
- Move all non-Autoware related repositories to the new CPFL organisation.
We will wait a week or two between the first two steps to give people time to update the URLs in
their local checkouts.
If you are wondering why we are renaming organisations rather than creating a new one for Autoware,
there are two reasons.
- It won’t mess with people’s subscriptions (we think).
- Our fearless leader likes his stars.
Also related to splitting the repositories is reorganising the package structure. I will start another
thread to discuss that, including how much we need to do before splitting the repositories and how
much can be done after. Please save discussion on that topic for that thread.