[Proposal] Improving the Autoware Repository Structure for New Contributors #6587
Replies: 7 comments 12 replies
-
|
I highly suggest adding a The other options all bring unnecessary complexity and/or chaos. Also let's move the ❌ Merging autoware_core into autoware repositoryWe have already did so many migrations and created so much confusion in our history. Right now the roles of the repositories are clear, modular and we have precedent https://github.com/ros2/ros2 Also versioning ❌ SubmodulesThis makes us lose too much flexibility. One example is, "Submodules are designed to pin an exact commit." so we won't have nightly anymore. Making development harder. Right now we (and the autoware integrators) have modularity with what repos to pick. With git submodules, this wont be possible. Also it will become complicated when people fork both this meta-repo and some sub-repos. If someone tested if where a submodule is modified to point to some other repo, please let us know. |
Beta Was this translation helpful? Give feedback.
-
|
I prefer option 3 because options 1 and 2 decrease modularity and increase complexity. As for option 3, I think we can not only tell newcomers where the code is, but also tell them how to get the code. |
Beta Was this translation helpful? Give feedback.
-
|
Definitely the short-term goal should be option 3, but I don't get why submodule should be hated this much. I don't think submodule ever compromises our development flexibility, but even if it did, I would still prioritize observability over flexibility as we're dealing with safety-critical software. |
Beta Was this translation helpful? Give feedback.
-
@xmfcx cc @mitsudome-r |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
@mitsudome-r Thank you for this proposal! The need for this changeThis is a sorely needed improvement: my first experience with Autoware four years ago was quite rough and I did not at all enjoy using it: the main branch didn't build most days. While this has gotten better, the
I would strongly favor your option 2: Git submodules are a well-understood and battle-tested mechanism for meta-repos. The very fact that they always point to a fixed Git revision ensures that an update to a dependency (e.g. About submodules
I don't think this is true. When using submodules, users, including us developers, can be certain that whenever they Currently, this check is burdened on users: users pull Autoware and try to build, (hopefully) creating an issue when there are problems. Or worse, people get cynical and fix the issues silently only on their machine, or use old versions of Autoware that are known-good. Most people around me are of the cynical kind and are using old Autoware for months on end. The That CI would run either
Its changes would only get merged if the build succeeds with the updated dependencies. Note that this does not restrict developers:
ConclusionThere are no numbers on this, but having talked to people about this, I suspect that the current issues cost us dearly in terms of new contributors and industry adoption. At one trade show, a person commented that Autoware doesn't seem to be very good - they downloaded it and it didn't build. Submodules are a de-facto standard in the rest of the industry - even our competition is using them! |
Beta Was this translation helpful? Give feedback.
-
|
I prefer monorepo BTW 😉 Anyway, I also experienced the first trial of
I think this is not only the multi-repo strategy but also versioning. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Background
Currently, the main Autoware repository (https://github.com/autowarefoundation/autoware) appears empty, as it does not contain source code but instead relies on external repositories.
This structure has historical and architectural reasons, but for new contributors and industry partners, this leads to significant confusion:
These issues reduce Autoware’s approachability and hinder ecosystem growth. This proposal aims to:
Proposals
Option 1: Merge Autoware Core into the Autoware Meta-Repository
Move all source code from autoware_core into src folder in the autoware repository. Autoware Universe will be treated as extension to the Autoware repository and can be maintained via vcs .repos files.
Pros
Cons
Option 2: Replace VCS with Git Submodule
Replace vcs with git submoulde. The meta-repo becomes a user-friendly bundle.
Pros
Cons
Option 3: Add a src/ Directory with a README Explaining Where the Code Is
Leave the meta-repo empty, but create a src/ folder containing only documentation explaining the link to the code
Pros
Cons
Option 4: Keep Current State
Keep using vsc tools with autoware.repos files
Summary
Beta Was this translation helpful? Give feedback.
All reactions