Skip to content

Resolved Legacy Issues

Jump to bottom
Herb Kuta edited this page Feb 6, 2020 · 2 revisions

Resolved Legacy Issues

Revision: 1 Published: 2020-02-06

All of these legacy issues now have been resolved or moved to meta-ros GitHub issues.

  1. Should the manually created files contain a copyright notice? DECISION:
    • The ones that LG creates will have # Copyright (c) YEAR LG Electronics, Inc. as their first line. Exception: patch files, because the email addresses of their creators will contain lge.com.
    • The ones that LG modifies that have an existing copyright notice will have the LG notice immediately after the existing notice.
    • The ones that LG modifies without an existing copyright notice will not have one added.
  2. Should the commits to meta-ros be required to have a Signed-off-by: line (see here)? DECISION: No (at least for now).
  3. Should the ROS packages be installed under /opt/ros/<ROS_DISTRO> or folded into the rest of the OS under /usr? If the latter, then where should what's installed by the *-vendor packages be placed? Selecting the former would seem to guarantee that ROS 1 packages can be added to ROS 2 distros, but would violate the Filesystem Hierarchy Standard because ROS is not an add-on, but fundamental to the operation of the image. Discuss at meta-ros.git #639. DECISION: The ROS packages will be installed under /opt/ros/<ROS_DISTRO>.
  4. Does rosdep init; rosdep update need to be run to use the ROS 1 or ROS 2 runtimes? (For ROS 1, this states "yes". For ROS 2, it's not mentioned here, so that implies "no".) DECISION: Yes for TurtleBot 3 under ROS 1. Although the melodic ROS 1 runtime appears to operate correctly without running them, turtlebot3_bringup turtlebot3_robot.launch outputs that the rosdep view is empty: call 'sudo rosdep init' and 'rosdep update' => create a package with the files that these commands create and include it in the TurtleBot 3 ROS 1 images.
  5. Should there be separate branches in meta-ros for each OpenEmbedded release series, or should [master] attempt to support them all. DECISION: Have separate branches in meta-ros for each OpenEmbedded release series. This will allow the layer to be able to achieve "Yocto Project Compatible" status (as can be inferred from the program's registration page ).
  6. Are there some packages whose nature is such that it doesn't make sense to build them with OE?, ie, they would never be run on an actual robot. Discuss at meta-ros.git #640. DECISION: There will be "developer" images defined that contain packages such as RViz and rqt (and their plugings) that would only be needed during development. Will not define "developer" images; users can create their own "developer" images containing whatever packages they want.
  7. Is the specified metadata versioning convention acceptable? DECISION: Apparently it is.
  8. Is the value of MAINTAINER correct? DECISION: It should be the lead maintainer of meta-ros.
  9. OpenEmbedded thud has later versions than Ubuntu bionic-updates of the following packages depended on directly by melodic, crystal, dashing, and eloquent packages. Must any be downgraded? DECISION: Apparently not.
  10. OpenEmbedded thud, webOS OSE , and Ubuntu bionic-updates all have different versions of packages depended on directly by melodic, crystal, dashing, and eloquent packages. Does it matter? ANSWER: Apparently not.
  11. Should the recipes for the components found in files/<ROS_DISTRO>/newer-platform-components.list be moved to a separate recipes-ros-infrastructure or, better, recipes-extra tree? DECISION: Move to recipes-infrastructure because most of them are in the ros-infrastructure GitHub organization.
  12. Is there any value in having separate includes-{ros1,ros2} trees? Having a single tree would simplify certain things, such as knowing which tree under which to add .inc files for a new component. DECISION: Experience has shown that there is no value in having this distinction.
  13. Since all OE metadata is MIT-licensed, should change the "Distributed under the terms of the BSD license" generated line be changed to say "MIT"? Or, perhaps, drop the line entirely? DECISION: Drop the line.
  14. Should the OE PR variable be appended to the same way as meta-webosose does? DECISION: No. The recipes will not assign PR.
  15. Are the package.xml files needed at runtime? ANSWER: Yes, at least for ROS 1.
  16. Should runs of superflore be dropped when the only change is to ROS_SUPERFLORE_GENERATION_DATETIME? The problem with doing this is that looking at the modified date on http://repo.ros2.org/rosdistro_cache/<ROS_DISTRO>-cache.yaml.gz (or http://repositories.ros.org/rosdistro_cache/<ROS_DISTRO>-cache.yaml.gz), it will appear that a run of superflore is needed. DECISION: Yes. The cache.yaml.gz files are regenerated periodically regardless of whether anything has changed, which means no one will expect a new modified date to indicate that content has changed.
  17. Could a field be added to package.yaml to indicate that the package is never to be added to an OE image? DECISION: Not needed. We will attempt to have the *-image-*-world images build and install as many packages as possible.
  18. Could a field be added to <ROS_DISTRO>-cache.xml to name the release of ROS_DISTRO that the file is for (eg, "Patch 3")?
  19. Could fields containing the MD5 and SHA256 checksums of the source tarballs be added to <ROS_DISTRO>-cache.yaml. Doing so would greatly speed up superflore because it wouldn't have to download them to compute the checksums. DECISION: The switch to generate recipes that use the Git fetcher in layer version 3 eliminates the need for this.
  20. Should the values of DISTRO_FEATURES specify capabilities of robots instead of groups of packages? DECISION: Yes, in general, though there might be cases where it still makes sense to do this. All existing ones will be renamed to be prefixed with ros-trial- instead of ros- in layer version 3.
  21. Should packagegroup-ros2-world be dropped? DECISION: Yes. The latest builds of webosose:build-webos now fetch from the '[legacy]` branch, so there is no chance of breaking it by removing this packagegroup.
  22. Should the ament-* and rosidl-default-generators packages be removed from the ROS 2 images? DECISION: Yes. They will appear in the "developer" images. Will not define "developer" images; users can create their own "developer" images containing whatever packages they want.
  23. Should python3-argcomplete for command completions (see https://index.ros.org/doc/ros2/Installation/Linux-Install-Debians/) be added to the images? DECISION: It will be added to the "developer" images. No. Users can add it to their images if they want it.
  24. Should ROS_HOME be set (otherwise ROS 1 writes to /home/root)? Should ROS_LOG_DIR and ROS_TEST_RESULTS_DIR be set to be under /var/log? What about ROS 2 logs? CLOSED: Discussion moved to https://github.com/ros/meta-ros/issues/673.
  25. How best to incorporate WindRiver's work (https://github.com/wind-river/meta-robot, https://github.com/wind-river/wr-ros-demo)? CLOSED: Discussion moved to https://github.com/ros/meta-ros/issues/674.
  26. Can support for raspberrypi3 can be dropped when support for raspberrypi4 is added? Discuss at meta-ros.git #664. DECISION: Yes, for OpenEmbedded release series after thud -- see Policies.

Revision 1

  • Initial publication.
Clone this wiki locally