Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REP 2005: ROS 2 Standard Library #225

Open
wants to merge 8 commits into
base: master
from

Conversation

@dirk-thomas
Copy link
Member

dirk-thomas commented Jan 12, 2020

This REP defines a curated list of ROS 2 repositories to provide community members with guidance regarding which parts of the ROS 2 ecosystem are widely used, actively maintained, and of high quality. Furthermore, we encourage contributors to focus their efforts on items from this list.

The naming "Standard Library" is following the same term of the Python Standard Library (but is up for discussion if a different term is proposed which describes the content better).

* `ros-visualization/rqt <https://github.com/ros-visualization/rqt>`_
* `ros-visualization/rqt_action <https://github.com/ros-visualization/rqt_action>`_
* `ros-visualization/rqt_console <https://github.com/ros-visualization/rqt_console>`_
* `ros-visualization/rqt_graph <https://github.com/ros-visualization/rqt_graph>`_

This comment has been minimized.

Copy link
@sloretz

sloretz Jan 14, 2020

Contributor

I'd link to to the repository page on index.ros.org instead of github directly. The repos sometimes move, but IIUC if the source entry is updated in ros/rosdistro then the repository page at index.ros.org will have a link to the new location.

https://index.ros.org/r/rqt_graph/

@Karsten1987

This comment was marked as resolved.

Copy link

Karsten1987 commented Jan 16, 2020

We'd appreciate if we could enhance this list with diagnostics. I am not sure whether to classify it as Tool or Feature.

@dirk-thomas

This comment was marked as resolved.

Copy link
Member Author

dirk-thomas commented Jan 16, 2020

We'd appreciate if we could enhance this list with diagnostics.

@Karsten1987 Sounds good to me. Please contribute the suggestion to the PR (either by committing directly to the branch or creating a PR). I would suggest to insert it in the Features section.

Signed-off-by: Karsten Knese <karsten.knese@us.bosch.com>
rep-2005.rst Show resolved Hide resolved
* `ros2/python_cmake_module <https://github.com/ros2/python_cmake_module>`_
* `ros2/rcutils <https://github.com/ros2/rcutils>`_
* `ros2/rcpputils <https://github.com/ros2/rcpputils>`_
* `ros2/ros_testing <https://github.com/ros2/ros_testing>`_

This comment has been minimized.

Copy link
@dejanpan

dejanpan Jan 16, 2020

I think that https://gitlab.com/ApexAI/performance_test has enough traction that it could be added here.

This comment has been minimized.

Copy link
@dirk-thomas

dirk-thomas Jan 17, 2020

Author Member

Sounds good, added in 84bcee1.

This comment has been minimized.

Copy link
@dirk-thomas

dirk-thomas Jan 17, 2020

Author Member

@ahcorde Can you comment on which additional repos might be useful here - specifically on the buildfarm integration?

This comment has been minimized.

Copy link
@dirk-thomas

dirk-thomas Feb 25, 2020

Author Member

@ahcorde Friendly ping.

This comment has been minimized.

Copy link
@ahcorde

ahcorde Feb 25, 2020

Contributor

For the performance test buildfarm integration we are using

This last one it's a fork of https://gitlab.com/ApexAI/performance_test we should fix some issues because the master branch is not working with cycloneDDS. We have two PRs open in this repo. I will put some time into fix them.

Potentially this repo (https://github.com/ros-tooling/system_metrics_collector) from the ros tooling group could be interesting

* `ros-perception/laser_geometry <https://github.com/ros-perception/laser_geometry>`_

* `ros-planning/navigation2 <https://github.com/ros-planning/navigation2>`_
* `ros-planning/moveit2 <https://github.com/ros-planning/moveit2>`_

This comment has been minimized.

Copy link
@dejanpan

dejanpan Jan 16, 2020

Autoware.Auto as a ROS2-based stack of algorithms for autonomous driving could also be listed: https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto.

This comment has been minimized.

Copy link
@dirk-thomas

dirk-thomas Jan 17, 2020

Author Member

I am not sure adding AutowareAuto to this list is a good idea. While all these algorithms are very valuable for a specific domain I am not sure if the are relevant enough for a large enough part of the overall ROS community. Maybe others want to weight in on this...

This comment has been minimized.

Copy link
@gbiggs

gbiggs Jan 20, 2020

I agree with @dirk-thomas. I think that Autoware.Auto is:

  • Still too niche
  • Still too early in development

to be included in the ROS standard library.

You could argue that MoveIt2 is also early in development, but I think they are starting from a more broad base (MoveIt 1) and have far wider applicability.

This comment has been minimized.

Copy link
@SteveMacenski

SteveMacenski Jan 21, 2020

I'd argue agreement with @gbiggs but with the opposite conclusion. While adding it to the standard library shipped with ROS2, I'd agree, but I think that it should be included in this list so there's incentives for companies doing open-source work on Autoware to make it less niche or early so it can then it better used.

This comment has been minimized.

Copy link
@gbiggs

gbiggs Jan 21, 2020

The problem is that makes it increasingly difficult to decide where to draw the line, which will become increasingly important the more things this list gets used for. If we let Autoware in, then why not Bob's Awesome Library for Pool-Playing Robots?

This comment has been minimized.

Copy link
@SteveMacenski

SteveMacenski Jan 21, 2020

I think since Autoware is being developed by many companies, used by many people, and arguably the only form of open-source ROS-based framework for the class of robots that is autonomous driving being seriously developed, I think that meets my spec. If it were just 1 company primarily sponsoring it (which I believe there are a few) or just 1 primary user (which I think again there are a few), I'd agree.

Bob's Awesome Library I don't think would make it if its just Bob developing it and primarily Bob using it.

This is an irritating suggestion, but maybe there should be a "ROS2 Standard Library Incubation" sublist, for projects that we want to count as TSC-representable projects, but aren't today mature enough to count as standalone projects. The phrase standard library implies a level of maturity that I agree Autoware doesn't have yet, but I don't think a decision on maturity was really the intention for this list to begin with.

This comment has been minimized.

Copy link
@dejanpan

dejanpan Jan 24, 2020

Hi guys, lets then wait until this becomes wider adopted. We currently have 12 companies working on a large autonomous valet parking project due in April 2020 and I we can asses the suitability for inclusion into the standard library afterwards..

* `ros2/launch <https://github.com/ros2/launch>`_
* `ros2/launch_ros <https://github.com/ros2/launch_ros>`_

* Features

This comment has been minimized.

Copy link
@dejanpan

dejanpan Jan 16, 2020

What is listed below are

  1. device drivers
  2. algorithms
  3. tools

So maybe we could split the list?

This comment has been minimized.

Copy link
@dirk-thomas

dirk-thomas Jan 17, 2020

Author Member

Could you propose a specific change here? Maybe through a PR?

rep-2005.rst Show resolved Hide resolved
rep-2005.rst Show resolved Hide resolved
@Karsten1987

This comment has been minimized.

Copy link

Karsten1987 commented Jan 17, 2020

How is this list supposed to work in terms of dependencies? So for example, the urg_node packages have a dependency on laser_proc which isn't listed here.

@dirk-thomas

This comment has been minimized.

Copy link
Member Author

dirk-thomas commented Jan 17, 2020

How is this list supposed to work in terms of dependencies?

The list should be self contained. So dependencies should be included too - otherwise you wouldn't be able to use some of these repos if their dependencies aren't available anymore.

So for example, the urg_node packages have a dependency on laser_proc which isn't listed here.

Please go ahead and (propose to) add them.

dirk-thomas and others added 3 commits Jan 17, 2020
Co-Authored-By: Kyle Fazzari <github@status.e4ward.com>
Signed-off-by: Chris Lalancette <clalancette@gmail.com>
Signed-off-by: Karsten Knese <karsten.knese@us.bosch.com>
@clalancette

This comment has been minimized.

Copy link
Contributor

clalancette commented Jan 17, 2020

The naming "Standard Library" is following the same term of the Python Standard Library (but is up for discussion if a different term is proposed which describes the content better).

Looking at the list of things that are in here, I'd suggest changing the name from "Standard Library". Some of the things that are on this list aren't available (as binary) from Eloquent, for instance, and there is no guarantee that all of these things will continue to be supported/released in the future. Hence, I wouldn't call them "Standard".

Some suggestions instead:

  • "Curated Library"
  • "Currently supported Library"
  • "Suggested modules"
@dirk-thomas

This comment has been minimized.

Copy link
Member Author

dirk-thomas commented Jan 17, 2020

there is no guarantee that all of these things will continue to be supported/released in the future.

The the Scope section we specifically aim that the repositories enumerated by this document by actively maintained. If that is not the case they shouldn't be on the list in the first place. Therefore I don't think the maintenance status alone is a good reason to consider changing the name of the list.

@mikaelarguedas

This comment has been minimized.

Copy link
Contributor

mikaelarguedas commented Jan 17, 2020

While having read it a couple times I am still having a hard time grasping the scope of this REP.

Are the criteria (widely used, high quality etc) aspirational or do they need to be satisfied already?


The REP seems to be distro and platform agnostic.
As a user, I would expect that the entire "Standard Library" works on my ROS distro as long as I'm using an active distro and a tier 1 platform/arch.
If this is a goal, it seems that packages not meeting that criteria cannot be part of it. If it is not the goal, a link to where users can find which part of the "Standard Library" is not supported on their distro/platform would be needed.

Maybe this REP can be re-targeted to be distro specific? Similarly to the variants REPs (e.g. REP142 or REP2001)

@gbiggs

This comment has been minimized.

Copy link

gbiggs commented Jan 20, 2020

The implication that "the content of the ROS standard library should be available on my tier 1 platform in the distro I am using", and the further implication of "the content should be available as binaries/via the package manager" warrent consideration.

I don't think it's something we need to deal with right now but I think we will increasingly face the criticism that we have defined a standard library but large chunks of it are not available for distro X on platform Y. This is a common occurence for many well-used libraries early on in the life of any distribution.

@SteveMacenski

This comment has been minimized.

Copy link

SteveMacenski commented Jan 21, 2020

How do we feel about generally used things like Robot Localization (or eventually Fuse)?

Also with Slam Toolbox being considered the new ROS2 "default" slam for navigation, should that be included? This one is mostly i think for me to be able to justify work time on improving things vs at home on the side. Also may pertain when I find additional maintainers.

@clalancette

This comment has been minimized.

Copy link
Contributor

clalancette commented Jan 21, 2020

The the Scope section we specifically aim that the repositories enumerated by this document by actively maintained. If that is not the case they shouldn't be on the list in the first place. Therefore I don't think the maintenance status alone is a good reason to consider changing the name of the list.

I don't think that status alone is a good enough criteria. When I think of the Python Standard Library or the C++ Standard Template Library, the following properties come to mind:

  1. Well-maintained code
  2. Widely applicable code
  3. Is installed by default (hence the name "Standard")
  4. Is available on all of the target platforms
  5. Has a well-defined lifecycle for introduction, use, deprecation, and removal

The list as I see it here satisfies property 1, and mostly satisfies property 2. But it doesn't satisfy the rest of the properties: it won't be installed by default (though we could), they largely aren't available on all target platforms, and the lifecycle for each of the package isn't guaranteed. For these reasons, I still think it should not be called the "Standard Library".

@gbiggs

This comment has been minimized.

Copy link

gbiggs commented Jan 30, 2020

@clalancette Ideally, which do you think we should be going for?

  1. Not calling it the standard library
  2. Calling it the standard library and trying to achieve all five of those criteria

I prefer option 2, with the content probably initially being lower-level and so more widely-acceptable libraries such as a base SLAM solution and MoveIt, rather than somewhat application-specific libraries. I accept that this means some libraries might have to be cut from the list and some organisations might find the things they want to contribute to not in the list, but I think from the users' point of view (which is what we should be judging by, not whether it enables someone to get on the TSC or not) and for the long-term health of the ROS ecosystem, option 2 seems to me to make more sense.

I said "initially" above because over time the Python standard library has grown to include libraries that do somewhat specific functionality, and I think the ROS standard library probably would as well as the community grows.

@SteveMacenski

This comment has been minimized.

Copy link

SteveMacenski commented Jan 30, 2020

Another couple suggestions:

  • ROS2 Ecosystem Libraries. As this is the ROS2 "core" + "foundational ecosystem" libraries
  • ROS2 Foundational Libraries. Similar concept, though I think this starts swaying back in the direction of "Standard"
  • ROS2 Supported Libraries. Might imply support where there is less support, but will give a clear indication that these are the libraries for people to support as part of contributions
@clalancette

This comment has been minimized.

Copy link
Contributor

clalancette commented Jan 30, 2020

@clalancette Ideally, which do you think we should be going for?

1. Not calling it the standard library

2. Calling it the standard library and trying to achieve all five of those criteria

I prefer option 2, with the content probably initially being lower-level and so more widely-acceptable libraries such as a base SLAM solution and MoveIt, rather than somewhat application-specific libraries. I accept that this means some libraries might have to be cut from the list and some organisations might find the things they want to contribute to not in the list, but I think from the users' point of view (which is what we should be judging by, not whether it enables someone to get on the TSC or not) and for the long-term health of the ROS ecosystem, option 2 seems to me to make more sense.

I agree with trying to achieve option 2 as well and calling it the "Standard Library". To get there, I think this REP would have to define the lifecycle for package introduction, maintenance, deprecation, and removal. Then each package on the list would need to address the 5 points. And in my mind, the criteria we come up with is not aspirational; it's a bar that a package would have to clear to get onto the list at all.

I said "initially" above because over time the Python standard library has grown to include libraries that do somewhat specific functionality, and I think the ROS standard library probably would as well as the community grows.

Yeah, agreed. All of the 5 points have some room for expansion.

@gbiggs

This comment has been minimized.

Copy link

gbiggs commented Jan 31, 2020

To get there, I think this REP would have to define the lifecycle for package introduction, maintenance, deprecation, and removal.

I do like this idea, but is it within the scope of the current issue?

@SteveMacenski

This comment has been minimized.

Copy link

SteveMacenski commented Jan 31, 2020

To go back to the original conversation I thought we were having in the TSC meeting: this list was, at its inception, to represent the items that "counted" as "ROS projects" for consideration for TSC membership. That list was also to act as the "ROS project" list that we consider to be central to the ecosystem for efforts to be applied to create high-quality development and maintainership.

The PR says

a curated list of ROS 2 repositories to provide community members with guidance regarding which parts of the ROS 2 ecosystem are widely used, actively maintained, and of high quality.

Which is markedly different in scope and context. This implies that projects on this list must already be of that high-quality, actively maintained, ... If that is true, we can go ahead and remove half of the ros-perception repos, nearly all the ros-drivers repos, and arguably many others (nav, moveit, ...).

If something on this list must already be high quality and its inclusion makes it "count" for TSC membership, that would heavily reduce incentives for members to work on the projects not yet meeting that criteria. Worse, creates a high likelihood projects not included couldn't or wouldn't get to that level to be included at all. Given in the past the ROS-perception packages haven't gotten alot of love from the community but are heavily relied on, removing TSC incentives to work on it would basically put us back to where we started with (a skeleton crew of volunteer maintainers). I view that creating an institutional incentive for regression.

That seems not the intent of the origin of this list. It seems to me we need, in reality, 2 lists. One for the Standard Library of high-quality projects that this PR's description fits and another ROS Ecosystem libraries with potential to graduate to the Standard library. Both of which "counting" for membership and as projects that are "parts of the ROS 2 ecosystem are widely used", regardless of its current quality level.

Not trying to throw a wrench into things. I just don't understand how we got from point A to point B in this implementation. I want to see the correct incentives to work on "important" things in the community, regardless of its current status. If I'm totally off base, let me know... The worst I can be is wrong 😉

@gbiggs

This comment has been minimized.

Copy link

gbiggs commented Jan 31, 2020

I think the bit that has got you caught up is the "high quality" aspect. It's arguable that this applies to most of the stuff outside of the core libraries, which is obviously not the case for something like all the libraries in the Python standard library. I think a good solution there is either your proposal, having two lists, or having a transition period. I think the former is less risky in terms of random users thinking "the ROS standard library is crap!" due to encountering bugs during a transition period.

@clalancette

This comment has been minimized.

Copy link
Contributor

clalancette commented Jan 31, 2020

That seems not the intent of the origin of this list. It seems to me we need, in reality, 2 lists. One for the Standard Library of high-quality projects that this PR's description fits and another ROS Ecosystem libraries with potential to graduate to the Standard library. Both of which "counting" for membership and as projects that are "parts of the ROS 2 ecosystem are widely used", regardless of its current quality level.

I like this proposal; it gets us the best of both worlds. It is a bit more complex for newcomers to grasp, but I think that is alleviated with some good explanation as to what exactly each list means.

@gerkey

This comment has been minimized.

Copy link
Contributor

gerkey commented Feb 18, 2020

I'm sympathetic to the desire to have a more precise categorization, but I don't agree that two lists are better than one. To date, we've had zero lists and it's taking quite some discussion to agree on what goes into the first one. Adding a second list will entail extra discussion about the best fit for every repo under consideration, now and in the future. And, worse, it'll give us an escape hatch that we'll over-use: it'll always be easier and safer to keep stuff on that second-class, less-strict list. As engineers we're never going to voluntarily call anything "done" or "ready", and if we have a "not-quite-ready" bucket available, everything will go there.

So I want one list. But I don't want it to be misleadingly named or described. A little aspirational, perhaps. For folks who are concerned with the language used in the Motivation or Scope sections: what changes would you like to see to be comfortable with including all or nearly all of the repos currently on the list in this PR?

The question of whether to target the REP at a particular distro is fair. I'm not sure what the right document-control process is. In principle I would expect that each new distro latches the Standard Library contents at some point during development and then ships with that latched list. To put that principle into immediate action, I'd expect that everything on the initial list we're building now will ship with Foxy. By "ship with" I mean that we aim for every item to be bloom-released and available in binary on supported platforms. We'll necessarily fall short of that goal for a variety of defensible reasons, and we should clearly note the exceptions (e.g., a driver that only works on Linux, or a test suite that doesn't make sense to release or install).

@gbiggs

This comment has been minimized.

Copy link

gbiggs commented Feb 18, 2020

As engineers we're never going to voluntarily call anything "done" or "ready", and if we have a "not-quite-ready" bucket available, everything will go there.

That's a fair point.

To put that principle into immediate action, I'd expect that everything on the initial list we're building now will ship with Foxy.

Can you put a date on that? It's common for many packages to "ship with" Foxy well after the initial release date. I'd prefer to be specific about whether we expect things to have binaries available on the release date or not, and "ship with" may or may not mean that depending on the person.

@gerkey

This comment has been minimized.

Copy link
Contributor

gerkey commented Feb 18, 2020

Can you put a date on that? It's common for many packages to "ship with" Foxy well after the initial release date. I'd prefer to be specific about whether we expect things to have binaries available on the release date or not, and "ship with" may or may not mean that depending on the person.

That makes sense to me. But I don't know what a sensible time limit would be. We can come at it from both directions: (a) based on our experience so far with ROS distros, how long does it take to get most of the useful stuff shipped? and (b) based on our understanding of users' requirements and expectations, how long will they wait?

@gbiggs

This comment has been minimized.

Copy link

gbiggs commented Feb 18, 2020

Probably it would be best to come at it from (a), tempered with (b) so we don't get lazy.

We should be loud about wanting to have everything on this list available from day 1, and ideally I think we need explicit reasons why not and expected availability dates for each missing package, although I acknowledge the level of work required for that.

Maybe we need a priority ordering, at least at the category level?

@SteveMacenski

This comment has been minimized.

Copy link

SteveMacenski commented Feb 18, 2020

what changes would you like to see to be comfortable with including all or nearly all of the repos currently on the list in this PR?

I would propose the following change:

With the curated list below we aim to provide community members with guidance regarding which parts of the ROS 2 ecosystem are widely used and actively maintained. , and of high quality.

Such that this list is about use and maintenance status. I don't think that REP-2004 should be a part of this REP. While it would be natural to assume that if things are heavily used and maintained also are high-quality, high-quality in this REP is illdefined. In the future when REP-2004 is in, the definition would likely cull down the then-appropriate repositories on this list.

@gerkey

This comment has been minimized.

Copy link
Contributor

gerkey commented Feb 19, 2020

@SteveMacenski That change works for me; can you submit it as a PR against this branch?

As a result the community size and overall project scope can scale up naturally and efficiently.

But in exchange, it can be difficult in a federated ecosystem for users and developers to know, of all the available ROS 2 packages, which are integral to the project.
With the curated list below we aim to provide community members with guidance regarding which parts of the ROS 2 ecosystem are widely used, actively maintained, and of high quality.

This comment has been minimized.

Copy link
@SteveMacenski

SteveMacenski Feb 19, 2020

Suggested change
With the curated list below we aim to provide community members with guidance regarding which parts of the ROS 2 ecosystem are widely used, actively maintained, and of high quality.
With the curated list below we aim to provide community members with guidance regarding which parts of the ROS 2 ecosystem are widely used and actively maintained.
@SteveMacenski

This comment has been minimized.

Copy link

SteveMacenski commented Feb 19, 2020

A suggested change may be faster

@clalancette

This comment has been minimized.

Copy link
Contributor

clalancette commented Feb 19, 2020

So I want one list. But I don't want it to be misleadingly named or described. A little aspirational, perhaps. For folks who are concerned with the language used in the Motivation or Scope sections: what changes would you like to see to be comfortable with including all or nearly all of the repos currently on the list in this PR?

So I guess I have two main concerns (which probably stem from the same place):

  1. Not all of the packages in this current list meet the criteria I identified here. Further, some of them cannot meet that criteria without significant additional work (for instance, some of the packages that I put on the list can't possibly work on Windows because they rely on underlying libraries that don't support Windows).
  2. It seems to me that we are committing the community to supporting all of these packages. If package Foo is available in Foxy, but then the developer disappears before G-Turtle, then we are left with two unappealing options: a) drop package Foo from this list, or b) find someone else to do the work to update that package and release it.

In combination with @SteveMacenski suggested change, both of these would be ameliorated for me by calling it something other than "Standard Library".

* `ros-infrastructure/bloom <https://github.com/ros-infrastructure/bloom>`_
* `ros-infrastructure/catkin_pkg <https://github.com/ros-infrastructure/catkin_pkg>`_
* `ros-infrastructure/rosdep <https://github.com/ros-infrastructure/rosdep>`_
* `ros-infrastructure/rosdistro <https://github.com/ros-infrastructure/rosdistro>`_

This comment has been minimized.

Copy link
@lokesku

lokesku Feb 20, 2020

We have lot of activity around OpenEmbedded support for ROS1/ROS2 in https://github.com/ros/meta-ros and its actively maintained.
Can we add this repo to the list.

This comment has been minimized.

Copy link
@lokesku

This comment has been minimized.

Copy link
@dirk-thomas

dirk-thomas Mar 19, 2020

Author Member

I would rather have others express their opinion since I shouldn't be the only one saying yes/no on those questions.

@ros-discourse

This comment has been minimized.

Copy link

ros-discourse commented Feb 21, 2020

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2020-02-20/12901/1

@gbiggs

This comment has been minimized.

Copy link

gbiggs commented Feb 21, 2020

Maybe I screwed something up or maybe I've been spending too much time at GitLab recently, but I thought a PR against this branch would show up here. Anyway, here's a PR that proposes some scheduling for when changes to the list go into effect.

#236


* Tools

* `ros-simulation/gazebo_ros_pkgs <https://github.com/ros-simulation/gazebo_ros_pkgs>`_

This comment has been minimized.

Copy link
@omichel

omichel Feb 21, 2020

Webots is being increasingly used by ROS2 users and Cyberbotics is committed to maintain the integration of Webots in ROS2 on the long term. This will be possible thanks to the support of several EU research projects including an upcoming ROSin FTP aiming at improving the ROS2 support in Webots and OpenDR that includes the use of ROS2 for Webots simulations. The Webots ROS2 Wiki page describes the current status of the integration which is fully functional and demonstrated in this ROS2 simulation of UR robots.

Suggested change
* `ros-simulation/gazebo_ros_pkgs <https://github.com/ros-simulation/gazebo_ros_pkgs>`_
* `ros-simulation/gazebo_ros_pkgs <https://github.com/ros-simulation/gazebo_ros_pkgs>`_
* `cyberbotics/webots_ros2 <https://github.com/cyberbotics/webots_ros2>`_
@dirk-thomas dirk-thomas mentioned this pull request Feb 25, 2020
@vmayoral vmayoral mentioned this pull request Mar 18, 2020
1 of 3 tasks complete
@ros-discourse

This comment has been minimized.

Copy link

ros-discourse commented Mar 20, 2020

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2020-03-18/13313/1

Change process
==============

This content is maintained at GitHub in the [REP repo](https://github.com/ros-infrastructure/rep).

This comment has been minimized.

Copy link
@deb0ch

deb0ch Mar 21, 2020

This link does not render correctly (brackets and url are showing) when using the view file link of this reviewing interface.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

You can’t perform that action at this time.