Looking at http://snapshots.ros.org/ it looks like there’s no support for rolling, is there any plan to support rolling in the snapshots repository .?
Is there something that I could do to help support it .? I would really be happy to help with that
Rolling binary package builds exist primarily to enable development, testing, and the exercise of the packaging and build system itself for forward development of ROS and I would say that relying on the provided artifacts with any expectation of reliability or stability is something that you should only do under your own peril. I am not in favor of providing snapshots of Rolling and the ROS team Open Robotics did discuss it briefly and decided against doing so when Rolling was first spun up. Additionally, Rolling’s inherent volatility means that snapshots of Rolling are going to be more storage intensive to produce than the snapshots of other stable distributions.
We are tagging the ros/rosdistro repository for rolling syncs so you could use rosinstall_generator to fetch Rolling sources from a specific sync in order to reproduce the state at that sync, you could even run your own build farm pinned to a specific rolling sync although I don’t necessarily recommend it. Alternatively, the snapshot system we use is a thin set of shell scripts wrapping the aptly utility so you could implement your own snapshots of Rolling if you desired.
Thanks for the offer. Contribution enables so much in this community. However, producing Rolling snapshots is not inhibited by time or labor, it isn’t being done due to the increased storage burden for snapshots (which could potentially be mitigated via sponsorship although I am not sure if that’s what you meant by support) but primarily because I, philosophically, do not want anyone to rely on or expect any kind of stability for Rolling and because we don’t want to support long term usage of any one sync of Rolling. Personally, I recommend that anyone using Rolling do so using the testing repository rather than the main ROS 2 repository and on my wishlist to implement is direct syncing from testing to main for Rolling so that there are no formal sync epochs for it at all. If that’s implemented I think it would make snapshots of Rolling prohibitively storage intensive and even less useful.
If you can share why you want snapshots of Rolling I would love to know the motivation behind the request. Ultimately the Rolling release is here to meet the needs of ROS developers and package maintainers so if there’s a need that Rolling snapshots would meet I would love to know what it is even if my immediate goal is to try and make an alternative recommendation that would not rely on snapshots of Rolling.
3 Likes
Jumping on the topic, its there any snapshot planned for Galactic ?
Thank you very much for the detailed answer
However, producing Rolling snapshots is not inhibited by time or labor, it isn’t being done due to the increased storage burden for snapshots (which could potentially be mitigated via sponsorship although I am not sure if that’s what you meant by support)
I would rather have it to the whole community than only internal to the company, I’ll ask to see sponsorship is an option
If you can share why you want snapshots of Rolling I would love to know the motivation behind the request.
We want to use the latest features/bug fixes for ROS2 while being able to freeze the version when needed (when we do hardware testing for example)
When snapshots first launched our targets were LTS ROS distributions on LTS Ubuntu distributions.
After the 2019 security incident we used the Snapshot repository to provide a permanent home to packages that we removed from the ROS repositories since we could not rebuild them on the re-provisioned build farm and have continued the trend to provide “final” snapshots for all supported platforms.
We were publishing snapshots for non-LTS ROS 2 releases prior to Galactic mostly because my fingers are occasionally faster than my brain. We decided for Galactic to adhere to our policy of only publishing snapshots for stable LTS releases.
I wouldn’t tell anyone their use case is invalid and if I were working on hardware platforms I would want the same thing. I would still prefer that those with the need to test hardware on a fixed set of Rolling packages do so by maintaining local mirrors since I would really like to avoid people casually using snapshots of Rolling and not providing public snapshots is a very efficient, but not the only, way to do that.
3 Likes