We should consider and publish Drake's timeline for supporting Ubuntu Trusty 14.04.
We shouldn't (and don't want to) drop support immediately, but we should come to consensus on a reasonable estimated timeline for doing so, to help inform our engineering planning.
My starting proposal would be something like this:
Actually, the GCC PPA that we already use on Trusty appears to offer even newer versions of GCC. Possibly it would be enabling to use GCC 5.4 for the runway of ROS-only support, if it was practical to switch the Catkin builds to using it. I don't know off the top of my head if other Trusty-based ROS or HSR C++ libraries have any C++ABI incompatibilities with the newer libstdc++ or GCC versions.
One additional thought: basically everything I do uses Travis for CI, so when I create an external project which uses Drake, I will also run that project on Travis. Since Travis still doesn't support 16.04 yet, using Drake post-Trusty will mean not using Travis, which probably means not having CI at all. That would be unfortunate.
from f2f: @patmarion says he's had success using 16.04 on Travis with Docker, using Docker files that @rdeits wrote.
Yup, also an option for sure. Setting up docker for Director was moderately annoying (at least a day of fiddling around with build systems), but it's probably better than not having CI.
@jwnimmer-tri who were the groups that were still using Trusty? I'll connect with them and start investigating the status/roadmap.
Great! I will respond offline.
Calling out to gather information about relevant parties and usage of Drake on Trusty. We are hoping to freeze Trusty sometime in the near future.
@peteflorence -- could you poll folks in lab and see if anyone is using / has a good reason for using Trusty?
@jwnimmer-tri Other groups we should consider?
Nope, I don't have anything else specific.
Could you poll folks in lab and see if anyone is using / has a good reason for using Trusty?
Note : would be perfectly fine to keep using Trusty at the point it is frozen. If at some time you'd like to take advantage of the new and shiny coming into master, then you'd have to jump.
The systems that will be the hardest to update are the ones on the robots. Atlas's onboard machines are all running Trusty, and I think Val's are too. I'm slightly nervous about upgrading the OS on those computers.
The systems that will be the hardest to update are the ones on the robots. Atlas's onboard machines are all running Trusty, and I think Val's are too. I'm slightly nervous about upgrading the OS on those computers.
As I mentioned, the trusty release will still be there, but not advancing (except perhaps the odd bugfix). Do you need the evolving tip of Drake on those systems?
good call @rdeits . this is a tough one. we are ramping back up on our experiments on those systems now. yes, definitely want them tracking master; in fact, they are likely to be pushing master.
I'm fine with making Spartan Xenial only but we should check with other users.
I'm also fine with making Spartan Xenial only, but I can only speak for users inside of TRI.
Relevant parties (location-robot-contact people) and when they are amenable to freezing a Trusty branch with the expectation that their would be limited merging between master and Trusty branches and either none/limited CI support.
At this point, there looks to be provisional support to drop (fully or partially) Trusty support in October 2017. Actions between now and then:
Just to be sure i was clear -- some of the robot apis are on trusty and are black boxes. I don't anticipate any troubles, and promised that we'd ask and/or try rolling forward all of the bots, but i don't feel like we can lock in a timeline until we learn a little more.
I should probably have put 'Confirm the decision' at 3 to avoid the confusion. Holding off for now until some time in September - is it likely the lab will have time to explore the problem before then? Am hoping we can review the problem and put in place a plan for going forward by October.
Update from the Val slack: the current blocker appears to be that upgrading Val to 16.04 implies upgrading to ROS Kinetic, and the orocos_toolchain package is not currently built for Kinetic.
I suspect you mean the orocos_toolchain?
Good catch, thanks. I've edited the comment.
Ach, sort of awkward with it's custom set of instructions, but it looks like it should be reasonably easy to upgrade and some have had success with it, e.g. here.
This might be something I can quickly help with if you need it. Just reach out if so.
Ok, thanks!
Proposing to freeze Drake Trusty support on October 6th with the following process:
The updated documentation and shambhala support may take a few extra days to realise.
Continued support and bugfixing for Trusty will cease from November onwards due to the lack of CI coverage and available human resources available.
Feedback welcome.
Trusty support has been removed from master. Bug fixes should be merged to the maintenance branch last_sha_with_trusty_support.
Most helpful comment
My starting proposal would be something like this: