Added Kinetic Kame #10443
Added Kinetic Kame #10443
Conversation
|
The build files are obsolete. We have moved to REP 143 and don't use REP 141 anymore. |
| # ROS distribution file | ||
| # see REP 141: http://ros.org/reps/rep-0141.html | ||
| --- | ||
| release_platforms: |
There was a problem hiding this comment.
This needs to list the Fedora version we want to support with Kinetic.
There was a problem hiding this comment.
I removed them because I wasn't sure we were building packages for Fedora in the buildfarm. Fedora isn't listed in ros-infrastructure/rep#106, should I update that too?
There was a problem hiding this comment.
We are not building Fedora packages on the build farm but we need to create the rpm stuff in the bloom process.
There was a problem hiding this comment.
Fixed. I've added 22 and 23, since they are the currently supported releases:
https://fedoraproject.org/wiki/Releases#Current_Supported_Releases
| release_platforms: | ||
| fedora: | ||
| - '22' | ||
| - '23' |
There was a problem hiding this comment.
@cottsay Does that sound reasonable?
There was a problem hiding this comment.
We need to be more aggressive, I think. We were off with Jade, which should have supported f23, which is the current release of Fedora.
I'm thinking 23/24/25 would be closer. However, if patterns hold, f26 would be dropping around June of 2017, which might mean that it falls before ROS-L releases, meaning that f26 wouldn't be supported on any ROS distros for some amount of time.
Going with 23/24/25/26 would be safer, but I think doubling the amount of RPM branches generated in Bloom would get really time consuming.
It would be interesting to look into a "shortcut" in Bloom for detecting when the generated branches will be exactly the same based on the resolved dependencies (which is REALLY common for RPM .spec files) and not generate those branches again...but I digress.
Thoughts?
There was a problem hiding this comment.
We can simply not support distributions which are not at least available as alpha when we start the release process. Therefore only 23 and 24 seems feasible to me. Also adding them later is not an option (the same with newer Ubuntu distros.)
There was a problem hiding this comment.
Then we will likely not support ROS on Fedora 25 in any ROS distros for the majority of it's lifetime. It is currently scheduled to drop 6 months before the release of ROS-L (assuming patterns hold).
I can't argue with your logic, but I want to make sure we all understand what the repercussions of leaving f25 off from the list are.
EDIT: for example, this is exactly what is happening now on f23, which isn't supported on Jade. f23 won't be supported until ROS-K drops.
There was a problem hiding this comment.
Yeah, it's unfortunate, but it's hard to see how we can cover all the releases with their cycle going twice as fast as ours. If it's only going to be a gap of 1 fedora distro then the users should always have a supported one. Though there may be lag as we spin up, like Wily.
There was a problem hiding this comment.
Right, I don't see any way around it. That's why I mentioned implementing some logic in Bloom and/or the buildfarm to use the "closest" version to the target platform version. I would say that 99% of the source RPMs built for ROS packages right now are the same across f20/f21/f22, so we could save generation time by skipping it all together if the rosdep keys resolve to the same RPM package names. If the version search logic was implemented in the buildfarm, this would also allow us to spin up additional platform versions after release - only the 1% of packages with differing keys would need to re-release in bloom - a very small price to pay, all things considered. If they aren't in the core package set, they could simply be left out until the package rev'd on its own.
I don't really want to get into this now, though. I'm sure we can poke holes in the idea in another thread.
For now, let's conclude that f23 and f24 should be listed here for ROS-K. Sound good?
There was a problem hiding this comment.
Sounds good we'll go with 23 + 24
There was a problem hiding this comment.
I've updated the file to only target 23 and 24.
|
I've squashed the commits and addressed the feedback, does this look good? |
|
This comment still applies. |
|
@dirk-thomas I've removed the build files, is that what you meant? |
|
Yes, but the current PR still shows new build files being added. |
|
@dirk-thomas my bad, I removed them in ros-infrastructure/ros_buildfarm_config#25 and thought I had removed them here. Should I remove them in ros-infrastructure/ros_buildfarm_config#25 too? |
|
No, only from this repo. |
|
I just reverted the last commit in ros-infrastructure/ros_buildfarm_config#25 and removed the build files from here. @dirk-thomas does this look good? |
|
LGTM. But don't merge it until the build farm is about to be deployed. |
Added release files for Kinetic