<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    I just wanted to add a +1 to both Tully and all the folks at OSRF
    for polling the community on this issue and working to find a
    well-balanced solution.  It just confirms my belief that ROS is here
    to stay and will continue to take over the world. :-)<br></div></blockquote><div><br></div><div style>+1 to that +1</div><div> </div><div style>As for my thoughts, as an academic who runs a lab in a university with a PR2.</div>
<div style><br></div><div style>+1 on LTS support, also +1 on supporting for as much of the Ubuntu LTS cycle as possible for a given ROS release</div><div style>+1 on lengthening the ROS release cycle</div><div style>Rationale: I don't like upgrading, since it takes away time from doing research.  Stability is (generally) what I care about most.</div>
<div style><br></div><div style>-1 for supporting every Ubuntu release</div><div style>Rationale: We have to draw the line somewhere, since there are limited resources.  I'm personally fine with having to install a particular version of Ubuntu for ROS, as long as I don't have to do it often.  I realize that this means some people will have to change their Ubuntu versions, and that this will cause some pain.  However, for me, this pain is outweighed by the simplicity and better use of resources.</div>
<div style><br></div><div style>+1 for an LTS version of ROS</div><div style>Rationale: Maybe this is outside of the regular release cycle, and perhaps it's maintained by a subset of the community.  For a lot of things that I do, I don't care what version of ROS I use.  My students often work on a small part of the ecosystem, on a particular problem.  Having that be stable is very valuable.  Having them be able to work on the same version of ROS for their entire PhD has some value (for some suitable definition of "the same version").  Yes, I'm talking about a 5-year support tied to the Ubuntu LTS schedule.</div>
<div style><br></div><div style>+1 to thinking about other approaches</div><div style>Rationale: Thibault's commend about thinking about a variable-length release cycle is something we should think about.  Perhaps we should release a new version when we're ready.  Of course, this means that we need to think about what "ready" means (which robots are supported, etc).  I haven't upgraded to groovy yet, because PR2 support wasn't in place until recently.  I'll probably do the change next week, and would probably ignore Hydro (on the old release schedule) until PR2 support was in place.  Austin's doing great work with the PR2 support, but he's rate-limited.   I'd probably be happy if one of the release criteria were: works on {set of robots including PR2 and Turtlebot}.</div>
<div style><br></div><div style>+10 for stability</div><div style>Rationale: I want (my students) to spend time doing science, not installing new versions of stuff and migrating code.  Even a week doing this every 6 months is (about) 5% of their time, which, over the course of a 5-year PhD amounts to 3 months of upgrading.  That's another paper that they could have written.</div>
<div style><br></div><div style>-- Bill</div><div style><br></div></div></div></div>