[ros-users] [Discourse.ros.org] [Autoware] Splitting the Autoware.AI repository and changing the organisation
Dave Coleman via Discourse.ros.org
ros.discourse at gmail.com
Fri Mar 8 21:57:31 UTC 2019
[quote="gbiggs, post:16, topic:8139"]
However, one of problems we have is the sheer number of packages.
[/quote]
For MoveIt, we have packages within folder groupings (left over from stacks). For example [moveit_planners](https://github.com/ros-planning/moveit/tree/master/moveit_planners) is just a stack containing more packages.
[quote="gbiggs, post:16, topic:8139"]
Im 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.
[/quote]
That may work, cool idea. I'd be interested to follow the progress of this, and any learnings.
[quote="gbiggs, post:16, topic:8139"]
PRs that require changes in another repository should be coordinated with those other PRs to be merged as simultaneously as possible.
[/quote]
In some projects we use a Github competitor called [Gerrit](https://www.gerritcodereview.com/), 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.
[quote="gbiggs, post:16, topic:8139"]
commercial entities wanting to build custom combinations of bits of Autoware
[/quote]
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]" ?
[quote="gbiggs, post:16, topic:8139"]
Id love to see those!
[/quote]
See "Visibility" section in [Bazel docs](https://docs.bazel.build/versions/master/be/common-definitions.html)
---
[Visit Topic](https://discourse.ros.org/t/splitting-the-autoware-ai-repository-and-changing-the-organisation/8139/23) or reply to this email to respond.
More information about the ros-users
mailing list