On 18.02.2013 19:10, Yamokoski, JD (JSC-ER)[OCEANEERING SPACE SYSTEMS]
wrote:
> Software as complex and as large as ROS will have some bumps and
> bruises at a major release - but from the outside looking in, it
> appears as though too much was changed in this release (as evidenced
> by the above plus the longer than normal release cycle).
After Tully's response I'll add some comment to this now. Please
consider also the following facts. Up to fuerte, ROS releases were
managed by Ken Conley, who left for Google as announced in April 2012.
So release management switched hands (I am not implying Tully is less
capable, but I do know he has had several other dominant assignments at
Willow Garage).
Also, in 2012 employees also left Willow Garage for spin-offs like
Industrial Perception, OpenPerception OSRF and HiDof, as well as other jobs.
So among the people that left ROS world in 2012 are: Ken Conley, Troy
Straszheim, Radu B. Rusu, Eitan Marder-Eppstein, Wim Meeussen, E. Gil
Jones, Stu Glaser, Bhaskara Marthi (in random order). I would also count
Brian Gerkey as being absent from the ROS world 2012 as far as ROS
engineering goes, because building up OSRF itself seems to have been a
lot of work with also a strong focus on Gazebo. If you don't know those
names, you'll find most of them in this list of all time ROS
contributors:
http://www.ohloh.net/p/ros-pkg/contributors?query=&sort=commits (though
that list does not span all of ROS, and needs updating for the switch to
github). This does not count non-Willow Garage staff that moved away
from the ROS world, such as PhD students being now finished and taking
up jobs outside the ROS world.
Also note many of the poeple I listed left ROS world without doing any of:
- Announcing their departure to the ROS community
- Nominating successors as maintainers for the packages they maintained,
or declaring the packages unmaintained
- Handing over issues assigned to them in issue trackers
Those ROS contributors also held a lot of knowledge about their packages
and the ROS toolchain that had in the past been useful to prepare and
validate previous releases, this knowledge was not available for the
Groovy release. I can only guess that hiring and training new talents
with such high fluctuation of key members of the ROS team cannot be
expected to go smoothly.
So the problems you noted as well as the release date slippage are not
(only) due to too many changes in the Groovy release.
(text/plain)