MoveIt Maintainer Meeting Recap - March 28 2019

MoveIt
1

Moveit maintainer meeting 03/28/2019

Agenda:

  • Feedback on MoveIt 1 release process, code freeze policy
    • Which branch to release from?
    • When is our next MoveIt 1.0 release going to be?
    • What will the release branch be called?
  • Progress on MoveIt 2 and request for help
  • Thoughts on CODEOWNERS effectiveness
  • How can the community dismiss stale reviews?
  • Tesseract-related Collision Checking improvements as discussed at ROSCon with SwRI
  • Other topics?

Attendees:

  • Jorge Nicho
  • Isaac Saito
  • Dave Coleman
  • Nathan Brooks
  • Anas M
  • Andy McEvoy
  • Andy Zelenak
  • Bryce Willey
  • Felix Von Drigalski
  • Henning Kayser
  • Jon Binney
  • Levi Armstrong
  • Mike Lautman
  • Robert Haschke
  • Simon Schemeisser

Discussion:

Notes taken by @Jorge_Nicho

  • Repository status:
    • Currently only 20 PRs.
  • Moveit 1.0 release and branch:
    • Minor back fixes should go to the melodic-devel branch
    • API and ABI changes go to the master branch
    • @davetcoleman : all new development should go to the master branch. Changes applicable to the melodic-devel branch will be decided on a case by case basis.
    • Suggestions for how to make it easier for developers to develop with the latest MoveIt, build takes too long:
      • Use Launchpad to build a debian from the latest code in MoveItto facilitate using the latest features/changes in move it without building from source.
      • Gitlab CI packages the build as debian packages.
      • Gazebo build process could be a resource to look into
      • White and blacklisting packages to speed up the build. (Moveit setup assistant, MoveItvisualization take a lot of time). Setup a default build that is more lightweight and builds faster.
  • Move 2.0 Acutronic update from Anas M:
    • Currently porting Moveit Core and planning scene monitor.
    • Working on minimally working example. Move Group tutorial in the works.
    • Current effort is focused on porting ROS1 to ROS2 code, not new features or significant design changes.
  • CI for ROS 2.0
    • @mlautman has prepared a Docker container with a travis script and the required dependencies.
    • Clang requirements will be relaxed or disabled.
  • Code Owners:
    • @nathanbrooks : Code owners file allows automatically assigning reviewers to PRs by matching a maintainer based on files/packages/directories.
    • Reviewers are assigned after PR creation.
    • Reviewers need to be under the “ros-planning” organization.
  • Stale Reviews:
    • In the PR, comments or questions should be entered as github comments instead of a “change request” as it keeps the PR from being approved for merging.
    • Stale comments or change requests can be overwritten if originator cannot follow up in time. Two other reviewers could overwrite a stale change request.
  • Tesserac integration
    • Meeting in Automate conference 2019
    • Google summer of code program could be leveraged for this integration effort; It would be helpful to produce a write-up of what this integration effort entails.
  • Other Topics:
    • Drop the exclamation mark and just call it MoveIt
1 Like
2

Remembering the discussions when the migration to a single repository was considered, this would seem to be one of the potential issues that were raised.

It’s unfortunate that we’re running into this so “soon” already.

Anecdotal, but I’ve recently had to explain to a potential contributor that it is still possible to build parts of MoveIt by just copying the packages out of the local ros-planning/moveit clone. It was completely unclear to him that this was possible.

Rather inconvenient work-around of course.

Edit: on my own system I have ccache with distcc installed. After an initial build (which does take a bit of time), a complete rebuild of ros-planning/MoveIt takes mere seconds.

1 Like
3

Remembering the discussions when the migration to a single repository was considered, this would seem to be one of the potential issues that were raised.

I know I’ve argued this plenty before, but I don’t see a strong relationship between number of git repos within the MoveIt project and build time. Almost all of the packages in the consolidated repo are arguably needed on a regular basis. Most people like the high level interfaces like the MSA, ROS interfaces, and Rviz plugin. Assuming you like having those around… you need to build all of MoveIt.

However, to make it even easier to disable packages, I totally refactored the source install instructions just now:

Edit: could you document how you use ccache and distcc on the source install page, please? That would be really useful to a lot of people.

2 Likes