ROS is a large diverse ecosystem but on thing that makes it very powerful is the availability of binary packages on the common supported platforms. It is a large effort to make this happen and much of it comes from volunteers throughout the community.
The process
Many in the community are not aware of the process for making releases. Here’s a quick summary for background.
Each time a rosdistro comes out we start from scratch and release packages in dependncy order. A rosdistro release is considered complete and ready to announce when all packages contained in the standard metapackages are available. The metapackages are defined in ROS Enhancement Proposals(REPs, most recently in REP 142
However the packages covered in the metapackages is only a small subset of the larger ecosystem. From those several hundered packages rosdistros can grow to several thousand packages. This process is an incremental process and over time the number of packages in a rosdistro grows as more maintainers make releases. In every release announcement there are almost always new packages made available together with the upgrades. F
The process is slow because it requires maintainers to release in dependency order. Depending on how many other packages a given package depends upon it may not be possible to try to release it or even test it. This can be especially slow if an underlying dependency has changed and requires code refactoring, and not just running the release process. An example is something like the change from Qt4 to Qt5. all gui packages are in the process of transitioning which is non-trivial work.
ully integrated systems such as support for a robot like the TurtleBot often come out a few months after the initial rosdistro release date because it needs to wait for all it’s dependencies to be released, and then it will need to be tested to be working before it is released. In this last cycle we pushed hard on the TurtleBot to get it out early, but it’s a comparatively small depndency list compared to the PR2 which often is a year or more behind before it’s fully released on a rosdistro.
How to make a request
When you make a request keep in mind the standard etiquette guidelines for all ROS communications. http://wiki.ros.org/Support
It is important to keep in mind that maintainership is done by volunteers throughout the community.
It’s important to express your interest in a certain package being released but respect that everyone else in the community has other responsibilities and deadlines. Often a simple request is enough to get a package released. A polite request which acknowledges how you will value the work that you are asking the maintainer to do will be way more effective. And if you can help the maintainer prepare the release and test the results that decreases the amount of work that the maintainer needs to do.
Recommended places to make requests
It’s recommended to make requests for packaging as github issues on the ROS package. Sometimes it may need to be on a release repository if it’s a 3rdparty package being wrapped into a ROS package. (For example opencv3)
If you’re interested in a collection of packages and there may need to be coordination between multiple maintainers the best place is the ROS Release categories on discourse.ros.org (for example kinetic: here
You can also raise awareness in the ROS release category if there has not been a response from the github issues. Sometimes email addresses have changed or notifications are not being recieved for other reasons.
Helpful things you can do to help maintainers make releases
When you’re making a request it can be very helpful to assist the maintainer. Here are some things that can help the maintainer.
- Verify that all dependencies are already released. (If not follow up to find what other releases need to be made first and help with them.)
- Test the to be released package from source and verify that it works correctly on all the target platforms. (This is one of the hardest parts of being a maintainer. As a maintainer you want to make sure that the package is working correctly before you release it. This is especially hard for hardware drivers where you also need access to the hardware to test.)
- Run prerelease tests to test and validate that new releases will work.
Please note that a maintainer is responsible for shepharding packages through the release process as well as merging validated patches. If you want new features other active development please consider contributing yourself. In the ROS community there is often a correlation between developers and package maintainers, however it is not necessarily the case, and is actually different than many other communities. Also even if the original developer is still the maintainer they may have other priorities and may not be able to focus development efforts on that package at the moment. So if there’s something blocking the release due to an incompatibility or failure pull requests to fix the problem can also significantly expedite the proccess.