GitHub or GitLab for Autoware.AI

Autoware
1

The Autoware Foundation was recently granted free usage of GitLab’s top-tier features, giving us some very powerful development management tools for free through their wonderful open source programme. We need to decide now how to make use of these tools.

Currently the plan that the AWF TSC has agreed to is

  • Put all Autoware.Auto development on GitLab under a group (the equivalent of a GitHub organisation) called autowarefoundation.

Ambiguously decided is:

  • Move Autoware.AI code to GitLab under the same group to take advantage of the new tools.

Not decided is:

  • What presence to leave at GitHub.
  • What to do about the thousands of stars that Autoware has at GitHub.

The maintainers are in favour of moving as much of Autoware.AI as possible to GitLab because it is easier to use one tool than two and because of the advanced tools we get at GitLab. There are multiple options for dealing with the undecided points.

  • Move all the code-containing repositories to GitLab and leave just the core autoware repository at GitHub. It will hold the autoware.ai.repos file used to install Autoware.AI and the stars.
  • Move all the Autoware.AI repositories to GitLab and leave just the a pointer autoware repository at GitHub. It will hold a README pointing people at the GitLab repository and the stars.
  • Abandon the stars and move entirely to GitLab.

The risk of moving is, of course, confusing or losing users, and the fact that the majority of the ROS community uses and is used to GitHub.

Of important note is that Autoware.AI is currently using GitLab CI, but this will probably not be possible after September when they are planning on ending free support for using GitLab CI for GitHub-hosted code. Additionally, over the next two or three years we expect Autoware.AI to effectively become an empty project that rebrands Autoware.Auto.

@shinpei0208 has proposed that the above is not the ideal plan. He proposes that instead we do the following:

  • Develop Autoware.Auto at GitLab under a group called AutowareAuto, taking advantage of the powerful management tools.
  • Develop Autoware.AI entirely at GitHub, as it currently is, in an organisation called AutowareAI.

That is the current state of things. Here’s my opinion:

I think that because the GitLab tools are powerful and useful, we should use them as widely as we can. This means not keeping Autoware.AI development at GitHub.

I also agree that the stars are a useful marketing point for attracting new users, so they cannot be lightly discarded. We have asked GitLab if it is possible to move the stars, but because they are effectively bookmarks it unfortunately is probably not technically possible except for users who have accounts at both GitHub and GitLab (unlikely for most users).

I think it is not possible to eliminate our GitHub presence entirely due to the risk of losing users and contributors.

I worry that leaving a repository at GitHub containing just the .repos file will require pointing users at that repository for installation, which might lead to them filing issues against that repository.

I think that using group names as project branding is nice but should not drive the name of the group because we will want to have non-Autoware (the software project) projects in the future.

So I propose that we:

  • Use a GitLab group called AutowareFoundation.
  • Use a GitLab sub-group called AutowareAuto that holds all the Autoware.Auto repositories.
  • Use a GitLab sub-group called AutowareAI that holds the Autoware.AI code repositories (shifted from GitHub).
  • Ideally, have the AutowareAI group also contain the core autoware repository that contains the .repos file for Autoware.AI, but I am willing to concede this if I have to.
  • Leave some kind of repository at GitHub to hold the stars and point new users at GitLab.
2

I’ve seen other projects host a read-only mirror of a non-GH repository on GH, exactly for the exposure.

Then point people discovering that repository (or those repositories) to the Gitlab hosted versions and explain all development and interaction happens there.

Perhaps that could be something for Autoware as well?

3 Likes
3

Does “read only” also apply to issues?

4

That depends what you exactly mean by “read only issues”:

  • you can disable the tracker on a repository, then make it clear that issues should be reported on the Gitlab tracker
  • as to mirroring issues: that is difficult, as you cannot faithfully mirror things like authorship and other properties between GH and Gitlab

The first I’ve often seen done, the second never really successfully.

Note that you can’t disable PRs, but you can clearly place a “warning” somewhere that PRs opened against that repository will be ignored.

Example: wireshark/wireshark.

1 Like
5

Though I agree that the stars may be important from a marketing perspective, I’d also like to point out that this is a topic that TSC has discussed extensively and reached a decision based on the research that, not only @gbiggs and I as coleads have done, but also by other members of the community.

Having Autoware.AI and Autoware.Auto in separate website would cement the idea that they are separate projects and fragment even further the community. What we want to achieve in the long term is to make the two converge into one single Autoware brand, and we can do that more effectively if the tools are the same for Autoware.AI and Autoware.Auto (hence the move to colcon and ament in Autoware.AI, for example)

I’m very much in favor of just keeping a repository on GitHub that only contains the .repos file, in the same way as https://github.com/ros2/ros2, and that will also keep the stars.