Splitting the Autoware.AI repository and changing the organisation

[davetcoleman]

@gbiggs

However, one of problems we have is the sheer number of packages.

For MoveIt, we have packages within folder groupings (left over from stacks). For example moveit_planners is just a stack containing more packages.

@gbiggs

I’m hoping to get nightly debians going with our own little package repository eventually which will allow us to test against recent versions of other repositories using binaries.

That may work, cool idea. I’d be interested to follow the progress of this, and any learnings.

@gbiggs

PRs that require changes in another repository should be coordinated with those other PRs to be merged as simultaneously as possible.

In some projects we use a Github competitor called Gerrit, used by Android, Chrome, etc. Gerrit has a cool feature that allows you to specify all the PRs from other repos it depends on, using a “DEPENDS_ON=” tag in the commit message. I’m sure something similar could be custom built for Jenkins/Travis.

@gbiggs

commercial entities wanting to build custom combinations of bits of Autoware

I’ve never liked this argument, though I hear it from the core ROS team a lot. What’s wrong with the catkin blacklist (tell CMake which packages to ignore) or adding a CATKIN_IGNORE file? Or simply “rm -rf [UNUSED_PACAKGES]” ?

@gbiggs

I’d love to see those!

See “Visibility” section in Bazel docs