-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added Kinetic Kame #10443
Added Kinetic Kame #10443
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
%YAML 1.1 | ||
# ROS distribution file | ||
# see REP 143: http://ros.org/reps/rep-0143.html | ||
--- | ||
release_platforms: | ||
fedora: | ||
- '23' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @cottsay Does that sound reasonable? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good we'll go with 23 + 24 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've updated the file to only target 23 and 24. |
||
- '24' | ||
ubuntu: | ||
- wily | ||
- xenial | ||
repositories: | ||
type: distribution | ||
version: 2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to list the Fedora version we want to support with Kinetic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. I've added 22 and 23, since they are the currently supported releases:
https://fedoraproject.org/wiki/Releases#Current_Supported_Releases