If you have created a pull request against the ROS 1 ros_comm repository in the past you have likely experienced a long wait until you have received feedback - and in several cases your patch might not have received any attention yet. Unfortunately this has become a more frequent problem in the recent past (and I am really sorry for that negative experience). So why is that the case?
I am the assigned maintainer of almost all packages in the ros_comm repository. Beside that I am also the designated maintainer of almost all ROS 1 packages which make up the ros_core metapackage as well as higher level packages like rqt. ros_comm is standing out here due to its prominent content but other “high profile” repositories like rviz are similar in this regard. ros_comm receives by far the most tickets - issues as well as pull requests. In the early ROS days it was often sufficient to file a ticket describing a problem or feature idea and “someone” would just go ahead and fix / implement it for you. That has been much less the case in recent years. At least on the pull request side I was able to review contributions in regular intervals (something around every few weeks). Unfortunately not only has that interval continuously increased also the time I am able to spend on actually reproducing problems, testing patches etc. has decreased significantly. That resulted in both: patches got merged which weren’t sufficiently tested and introduced regressions as well as many patches which haven’t been “accepted” until now.
To understand why that is the case I have to mention a bit about my work time at Open Robotics. As you’ve surely noticed over the past few years, our development focus is on ROS 2. We’re still maintaining ROS 1 on a best-effort basis, but my day-to-day priority is shifting more and more towards ROS 2 development. That priority is the result of both our decision as a company on where to focus our energy and the reality of what type and scope of work can be supported by the industry partners and government agencies that supply the bulk of our funding. As a result any time that I do spend on ROS 1 maintenance necessarily takes away from our current projects. And even without targeted funding, the company decides to continuously invest quite some discretionary resources into ROS 1 maintenance (through each of our employees) - consider the effort it takes us every year to prepare a new ROS distribution - beside the continuous work on issues and pull requests, running the buildfarm, etc.
Open Robotics doesn’t have the resources available to allocate to these tasks so we can’t expect any additional time to “magically” become available. Luckily there is already one external ROS developer helping to maintain the ros_comm repo (Thank you, Mike Purvis / Clearpath Robotics!). Without his efforts the current situation would be much worse. But the trend of me having less and less time as well as the load continuously increasing leads to the current unsatisfying situation as well as a not very positive outlook for the future.
So what can we do about it? Ultimately we need more people to volunteer to help with the effort of maintaining these packages. These contributions can come in many forms: review pending patches (which includes reproducing the problem, applying the proposed patch, reporting that the problem is fixed, additional testing to check for potential regressions), review incoming issues and provide users with help to fix them, help with other maintainer tasks like creating and testing patch releases, considering patches for backporting into “older” ROS distributions which are still being supported, investigating flaky tests, etc. A good way to start is to browse through the existing tickets and subscribe to the notifications on the repo so you will get emailed when new issues / pull requests are coming in, and some may pique your interest. While any kind of help is highly appreciated we are looking for people which want to help for a longer time period and on a regular base with these tasks. If you would like to “commit” to that kind of support please let us know and we are happy to get you more actively involved.
You left out the part where OSRF decided to make all of ROS2 independent and incompatible to ROS1, causing a split in the community, and duplicating all maintenance efforts. Don’t you think that this is part of the reason?
You do not mention the possibility of migrating the ROS1 community as a whole to ROS2. But maybe even OSRF has given up hope of achieving that anytime soon after making the migration path so difficult.
You really mean OSRF is looking to hand over ROS1 to some other organisation, like an actual open-source robotics foundation?
So will OSRF make a presentation at next ROSCon about how ROS1 is dead, given ros_comm is unmaintained? Might go nicely along with other presentations showing new ROS1 packages.
I would like to help, but I cannot really justify it to my employers at this point, when we are focusing on ROS2.
Also, I think QA on ROS1 has always been a problem and I don’t see a good solution.
So, how about trying the idea of a library shim, either instead of or in addition to adding maintainers to ros_comm?
I mean a ROS1 API on top of rcl. We could transition everybody much more quickly that way.
I know this has been talked about before, but not realized so far. Not sure why, but if it’s about the effort, a shim would be something I and probably many others could get involved in, because it’s about helping with the future ROS.
Thank you for offering your support. Please see https://github.com/ros/ros_comm/issues/1496 where I tried to give a high level overview how to help. Please feel free to ask questions on that ticket.
If you would like to contribute towards an API shim that would be great. We have had discussions about the topic in the past about how viable / complicated it would be, what to cover, what to do when the existing ROS 1 API can’t be mapped to ROS 2 etc. I would suggest to start a discussion in the “Next Generation ROS” category. I could also create repositories for this effort (e.g. ros2/ros1_shim) if you think that would be helpful to get things rolling?
While there were some comments offering help there was unfortunately no actual help contributed afterwards.
I am not sure what you mean with “ongoing process”? We are still hoping for others to help but have reached out numerous time with no effect and don’t know what else to do from our side.
I am spending every few months a little bit of time on catching up with pull requests. Currently I am still working through the tickets on lower level repositories before getting to ros_comm. And with the amount of PRs pending in that repo I doubt that I will have time to review all new ones before I have to drop the ball again for another few months. (I am sorry if that isn’t satisfactory but I want to set clear expectations.)
Sorry i just read the three volunteer prompts and missed the follow up over the Ros1/2 shim rant.
Maybe everyone else missed that too
The steps from the ticket include reading issues and creating pull request. Maybe people did read tickets and created pull requests: what now? Thumps Up PRs? I can imagine this is why none of the volunteers did help. I fell somewhat lost after reading the ticket - No Offense, just presenting my own thought process.
It feels like too much for a single person - Bus factor: There should be additional maintainers, right?
Probably yes. However, since ros_comm is the most important repo of ROS1, I hope that there’s a vetting process for new maintainers; like, potential new maintainers should first help answering issues, reproducing and testing PRs etc. without maintainer status (as described in the issue mentioned above). Once they’ve demonstrated that they are diligent and know what they are doing, they could get direct push access to the repo.
And no, just “reading issues” isn’t helping much - the goal is to comment on issues with the finding according to the triage process described in the above ticket. Just to copy some of the bullets from there:
Check if it is still valid
If it is a bug try to reproduce the reported problems
Consider creating a pull request to fix the bug / implement the feature request (always referencing the original issue)
If you don’t have the permission (yet) to set labels or close obsolete tickets please just comment with the suggestion and someone will follow up on it.
Also “thumbs up PRs” isn’t helping much since it is unclear what the reviewer actually did (beside that nobody gets a notification when you add an emoji to a ticket). Maybe the person just wants the problem to be fixed. Again some bullets on what we are looking for:
Check if it is still valid
All pull requests must target the latest development branch which is commonly also the default branch (currently melodic-devel ), the only exception is if a patch is only applicable to older branches and not necessary on the default branch
If the patch already has feedback which hasn’t been addressed by the author consider creating a new PR addressing the pending feedback to make the patch mergable (always referencing the original ticket)
Review the patch which includes:
Check the diff for problems (unnecessary / unrelated changes, incorrect / incomplete logic, API / ABI breakage, code style matching surrounding code)
Reproduce the problem without the patch
Apply the patch
Reproduce that the problem has been addressed and try to make sure that it doesn’t introduce any regressions
Some people probably want to help, but also might simply be intimidated/lack confidence (similar to what the MoveIt! maintainers brought up).
Not sure what could help other than to tell people (myself included) to “just do it,” since your instructions on #1496 definitely provide sort of a starting point.
