[ros-users] [Discourse.ros.org] [General] Proposed changes to the ROS releases

Geoffrey Biggs ros.discourse at gmail.com
Wed May 30 01:36:57 UTC 2018





[quote="clalancette, post:16, topic:4736"]

However, as you point out in several places, we dont really have mechanisms to enforce any of the guidelines, we just have to trust the maintainers to do the correct thing.

[/quote]



I think that you can, in that you can control what gets accepted into the release. But it would be more effort on your part to verify that maintainers are actually meeting their obligations. I think that Debian's use of its own bug tracker for all its packages is an aide to this for them. They can easily check how many open tickets a package has and what type they are. It's possible that some of the work coming out of the current quality assurance effort might provide something that can be used here. For example, the CI badge functionality can be used to automatically check that a package has CI, and is passing that CI, before it gets accepted into the LTS release.



But as you say, ultimately with the current nature of the ROS community, trusting the maintainers is necessary.



[quote="clalancette, post:16, topic:4736"]

Overall, Im not usually a huge fan of prolonged testing cycles. My experience has been that you get a flurry of activity right at the beginning or right at the end (sometimes both), but the middle sees little use and thus you get little value out of it.

[/quote]



I don't think the purpose of Debian's testing branch existing for two years before it becomes stable is to have two years of testing a single version of the package. It provides enough time for users to work with software that isn't blowing up but provides up-to-date features with further updates possible and gives them time to update their own stuff to match.



[quote="clalancette, post:16, topic:4736"]

Since maintainers have the ability to update their packages after a release

[/quote]



Maintainers upating their packages in an LTS release should have very very strict requirements on what is accepted (bug fixes only being an obvious one) to ensure that the LTS remains the same stable target it is at the start.



[quote="clalancette, post:16, topic:4736"]

Id rather see the release out there and then make improvements to it along the way.

[/quote]



I think that this is in conflict with the goal of the LTS release being a stable platform on which products can be built. I think it's also part of why Debian has separate unstable and testing rolling releases: testing is considered usable for non-critical applications (I know many people who use testing for their daily-use computer, but only one probably insane person who uses unstable for daily use) so it gets the package out there as you want, without making the stable release risky.



[quote="clalancette, post:16, topic:4736"]

Im generally in favor of failing loud and early, so Id lean towards the former, but we havent come up with any of those details yet.

[/quote]



I strongly agree with failing early. Users of the next release need as much advance notice as possible that something they depend on is going to disappear so they can plan and enact changes in their own stuff.



[quote="clalancette, post:16, topic:4736"]

The intent is that the packages will be taken from the last LTS into the new rolling distribution immediately after the LTS is released.

[/quote]



I would prefer the opposite approach: the rolling release should be on-going forever, and the LTS release should be a snapshot of it at a point in time. I do not see a benefit to restarting the rolling release every time a new LTS release is made. Is the intention here that testing for the LTS release is done separately from the rolling release and the rolling release becomes a new-features branch of the LTS release?



---



I think that much of this discussion is being driven by an unstated assumption about what the LTS release is intended to be. I would like the OSRF to make that assumption clear so we know what the goal is. Is the LTS release intended to be a stable platform for products to be built on and for use in critical applications, or is it a snapshot of package versions at a point in time that may be updated as package maintainers feel like it?



Put another way, does the OSRF see its position as like the Linux kernel developers, who release new kernels regularly but do not pay much attention to the testing necessary to ensure usability in critical applications and leave the production of releases for critical applications to others (the Debians and Red Hats), or does the OSRF see itself as like the Debian Foundation, providing a well-tested base on which applications can be built?



I'm not criticising either position because both are perfectly valid, it just needs to be clear. It will impact the release process requirements, how many resources the OSRF needs to invest, and what companies would then expect from a release provided by the OSRF. I hope to one day see a Red Hat emerge for ROS so if the OSRF does not want to be doing this work I do not think it is a disaster for ROS.











---

[Visit Topic](https://discourse.ros.org/t/proposed-changes-to-the-ros-releases/4736/17) or reply to this email to respond.









More information about the ros-users mailing list