Start of the version control for autoware.universe

[youtalk]

Through the discussion https://github.com/orgs/autowarefoundation/discussions/4671, all the packages belonging to the core directory of autoware have recently been version-controlled. https://github.com/orgs/autowarefoundation/discussions/4980

Next, we would like to begin the version control for autoware.universe, which is currently progressing at the fastest development speed in autoware.repos.

At TIER IV, we have been managing tier4/autoware.universe, which is forked from autowarefoundation/autoware.universe (or upstream), as Autoware has been integrated into TIER IV's products like Pilot.Auto.

https://github.com/tier4/autoware.universe

In the tier4/autoware.universe, unlike the upstream, we periodically merge the upstream differences and conduct release tests and simulation tests using Autoware Evaluator with a vast number of scenarios.
Then tags are applied to those that pass the tests, and they will be applied to TIER IV's products.

https://github.com/tier4/autoware.universe/tags

In this post, we propose to discontinue the forked repository tier4/autoware.universe and revert to using only autowarefoundation/autoware.universe.
We would like to conduct similar periodic tests directly on autowarefoundation/autoware.universe and apply version tags accordingly.

This will allow us to start the version control of autoware.universe in autoware.repos, dramatically reducing the chances of unintentionally breaking Autoware. We expect this to be a significant step forward in the version control of Autoware.
At this point, we will use catkin_generate_changelog for the version control, similar to the ROS 2 packages in the core directory. However, since autoware.universe is developing at a very fast pace, we do not plan to release them from the ROS build farm for the time being.

In the near future, we are also planning to gradually open-source the proprietary release tests and simulation tests currently being conducted at TIER IV, starting with those that can be made public. This will allow testing to be conducted in a true OSS environment without relying on Autoware Evaluator.

[kyoichi-sugahara]

@youtalk
Is it correct that we want to solve the issue of unintentionally breaking Autoware through version control? I strongly agree with this, as many users have reported that Autoware becomes unusable due to frequent updates in autowarefoundation/autoware.universe without proper version control.

On the other hand, I believe it is still necessary to manage tier4/autoware.universe for the following reasons:

• The modules and parameters used in tier4's products sometimes differ from those used in standard OSS (e.g. comment against autoware_launch's PR from tier4 developer, making it essential to have a separate framework for evaluation.
• The parameters tuned for products are competitive assets for tier4 and its partners in their own right.

I understand that the proposal includes stopping the management of the tier4/autoware.universe repository, and I am commenting on this point with concern. However, I fully support the main part of the proposal.

[kyoichi-sugahara]

I realized there was a contradiction in my thinking that autoware_launch has different parameters and therefore should be managed with separate test frameworks. Would running tests on the same snapshot for both autowarefoundation/autoware.universe and tier4/autoware.universe at the same time be a potential solution?

[armaganarsln]

This is great news. We don't have enough manpower to have 2 repositories. Please don't stop or make compromises during this change. We need unification of efforts as soon as possible.

[sasakisasaki]

@xmfcx @mitsudome-r As we discussed in the meeting, following ideas might help to provide the tag-fixed autoware.repos.

• Attaching tags monthly is even super helpful as it would be hard to review if all the repositories' version work weekly or around.
• As some people want to use the latest autoware.universe without its tag, we want to keep the current autoware.repos as up to now.
• On the other hand, having autoware.repos-latest-stable which contains repositories with its tag or commit hash helps to provide a stable build.

Personally, introducing autoware.repos-latest-stable looks good to me as the starting point for providing the build-able Autoware anytime.

Any your ideas are highly appreciated. Thank you so much.

[mojomex]

It would be awesome if the default would always build successfully. That would mean

• either making autoware.repos fixed and having a autoware-rolling.repos that is not fixed
• or changing the documentation so that new users use autoware.repos-latest-stable by default

I would personally prefer the first option as it aligns with ROS naming a bit more and the documentation does not need changing.

[sasakisasaki]

@mojomex Thank you for sharing your insightful views! I agree with the naming as it would be more familiar with ROS users. I believe if we have both the autoware.repos and autoware-rolling.repos with monthly update, lots of users can build the Autoware more and more comfortably anytime.

[sasakisasaki]

I'll prepare a PR as my first trial in one week (by 10th Oct.) 👍

[sasakisasaki]

Now preparing for push, ... . Hopefully will be done in a few hours!

[sasakisasaki]

Now I created the PR 👍 . Although I'm still doing double check, I assigned @mojomex as the reviewer.
#5323

[youtalk]

Thank you for your patience; I have started the version control work for awf/autoware.universe.
autowarefoundation/autoware.universe#9261

[youtalk]

autowarefoundation/autoware.universe#9266