REP3 proposal for Lunar Loggerhead

[tfoote]

@rmattes

First, what does “recommended support” for Fedora and Debian mean? That the build-from-source process should generally work? Or is there thought of adding binary releases for those distributions?

This means that we will do a best effort to support users on these platforms but not block if something is not available. It’s expected that building from source should be possible on those platforms. We generate the build metadata automatically for them (aka bloom-release is aware of them and turns them on by default) And we have enabled builds on Debian already in Kinetic and since it’s so close to Ubuntu there’s very little difference. If there’s interest from contributors to get Fedora binary builds working we would be interested in supporting bringing RPM builds online too.

@rmattes

Second, unless something in Fedora land changes, Fedora 25 will go EOL ~13 months after its release date[1], or around December 2017. Fedora 26, which will be released in the June 2017 timeframe[2], will be EOL around July 2018. Does it make sense to call out specific distribution versions when they won’t all be supported over the same timeframe as the ROS release? Or, in cases where a distributions future plans are unknown that far out, does it make more sense to just make a blanket statement that the earliest and/or latest supported version of that distribution should be supported by ROS?

The timing is unfortunate. The primary reason for calling out a specific version is that for our tooling, like bloom we have to pick specific versions for which to generate metadata. We can only support available releases since the dependencies need to be known. Our release is synchronized with the Ubuntu alpha cycle so that we can use their prerelease versions for development and extend our life cycle as far as possible. They have even shorter cycles than Fedora (9 months for non-LTS)

In the past we’ve tried adding platforms to ROS distros and that is as much work as creating a new rosdistro, and actually harder since you are not in a tick-tock cycle so deprecations upstream can box you into a corner. So we can’t plan to add 26 after our release. And the 26 Alpha looks like it won’t be available until mid march. (Fedora 26 Release Schedule )

@rmattes

That said, Fedora is already incompatible with the “Exact or Series” requirements. We’ve already got pcl-1.8 in fedora 24 and higher[3], and Qt 5.6 or higher in fedora 24 and higher[4]. On the other hand, we won’t introduce gazebo 8 or probably opencv-3.2 until fedora 26, as large breaking changes in released fedora versions violate the stable release updates policy[5]. So do they really need to be exact, or are they only enumerating the requirements as dictated by the environments on the “Required Support for” platforms?

It would be good to know what these will be and call them out. The goal is to have a consistent set of core dependencies that maintainers don’t need to worry about supporting multiple dependencies with #ifdefs or other mechanisms.

A few specifics.

• PCL on Yakkety and Zesty is already 1.8 as well. We should specify that’s more flexible.
• Our target of Gazebo 8 is to synchronize the Ubuntu LTS, with the ROS LTS, with the Gazebo LTS versions. To make this happen we will have to custom package Gazebo8 for the non-LTS ROS releases. And for the LTS releases we will have to at least package for the non-LTS ubuntu versions assuming the the Gazebo LTS is submitted successfully upstream. Though if we’re already building the non-LTS Ubuntu version for the ROS/Gazebo LTS coverage we might as well build new packages for the Ubuntu LTS in case of a patch release to get it out quicker and more consistently. So for Fedora I think it would be best if we packaged Gazebo 8 for Fedora 25 as well. @jrivero Do we already have rpm packaging of gazebo supported?

@rmattes Could you go line by line through the dependencies and start a thread on that line of the PR if there’s a discrepancy that needs to be resolved?