[ros-users] ROS Release Timeline

[Edwards, Shaun M.]

All,

I'm in agreement with Bill on all items except considering a variable release cycle(thanks Bill for doing all the writing for me).

As for any consideration for a variable release cycle, I think that too often leads to drawn out development cycles with pent up features and more bugs.  Schedules (and budgets, if we had one), force decision making.  They ensure that important features do not get hung up on unimportant ones.  By setting a goal(deadline), we make it much easier to decide or at least force the decision making process.  Does this mean that every release will come out on time.  No.  Groovy is a good example of this.  However, when we fail to meet a deadline we feel that pain, improve and move on to the next release.

For what it's worth, with a lot of software development teams moving towards more agile software development (i.e. small features, quick releases), we would be doing the opposite.

My two cents,

Shaun Edwards
Senior Research Engineer
Manufacturing System Department


http://robotics.swri.org
http://rosindustrial.swri.org/
http://ros.swri.org<http://ros.swri.org/>
Join the ROS-Industrial Developers List<https://groups.google.com/group/swri-ros-pkg-dev/boxsubscribe>
Southwest Research Institute
210-522-3277

From: ros-users-bounces at code.ros.org [mailto:ros-users-bounces at code.ros.org] On Behalf Of Bill Smart
Sent: Friday, May 31, 2013 2:14 PM
To: User discussions
Subject: Re: [ros-users] ROS Release Timeline


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. :-)

+1 to that +1

As for my thoughts, as an academic who runs a lab in a university with a PR2.

+1 on LTS support, also +1 on supporting for as much of the Ubuntu LTS cycle as possible for a given ROS release
+1 on lengthening the ROS release cycle
Rationale: I don't like upgrading, since it takes away time from doing research.  Stability is (generally) what I care about most.

-1 for supporting every Ubuntu release
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.

+1 for an LTS version of ROS
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.

+1 to thinking about other approaches
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}.

+10 for stability
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.

-- Bill

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130531/dd01458e/attachment-0004.html>