[ros-users] ROS 2.0 Strategy review

Wed Sep 30 21:59:53 UTC 2015

Hi Thibault,

For opensplice, I looked at https://github.com/PrismTech/opensplice/network
which makes it clear that most of the work is happening in branches
maintained by osrf . By comparison, the mainline has had a handful of
commits in 2015 and another handful in 2014.  Here:
https://github.com/PrismTech/opensplice/graphs/commit-activity Conclusion
is that the project is stagnant.

For https://github.com/objectcomputing/OpenDDS -- I see actually that it is
very active: https://github.com/objectcomputing/OpenDDS/graphs/contributors
 and none of it seems to involve OSRF people.  (Note that
https://www.openhub.net/p/opendds does not reflect this location; it shows
an older svn repo that has gone inactive)

For eprosima  I see https://github.com/eProsima/Fast-RTPS -- they have
other repos, but this seems to be the correct one to look at.  Its shows
some activity but few contributors.
https://github.com/eProsima/Fast-RTPS/graphs/contributors The other
eprosima reps seem to be similar.

In any case, the good news is that they're all on github, which does make
this kind of prowling around much much easier.

-- Linas

On Wed, Sep 30, 2015 at 2:53 AM, Thibault Kruse <tibokruse at googlemail.com>
wrote:

> Hi Linas,
>
> Some buildsystem changes are apparently linked to the move to DDS
> because OSRF wanted to make the vendor choice configurable, which
> required some changes over catkin. However other changes were made
> that are not linked to DDS, and with more effort could have been done
> in backwards compatible ways. [1]
>
> I am not sure which "DDS code repositories" you talk about. OMG does
> not have an own DDS implementation. Of the open alternatives
> OpenSplice seems to have low commit activity, while openDDS and
> eProsima seem to have more activity [2, 3, 4]. (Commit statistics can
> be misleading for Opensplice because they summarize commits into
> public release commits, but even knowing that it seems activity is
> low).
> Can you point to what you mean?
>
> regards,
>   Thibault
>
>
>
>
>
> [1] https://groups.google.com/forum/#!topic/ros-sig-ng-ros/gyToaPoiQi4
> [2] https://www.openhub.net/p/opensplice-dds
> [3] https://www.openhub.net/p/eprosima
> [4] https://www.openhub.net/p/opendds
>
> On Wed, Sep 30, 2015 at 2:46 AM, Linas Vepstas via ros-users
> <ros-users at lists.ros.org> wrote:
> > Agreed.
> >
> > Incremental, evolutionary changes rolled out on a shorter time frame
> seems a
> > much safer development course.  If there is a reason to couple API
> changes
> > to the build system to the network protocol, I haven't seen it.
> >
> > After seeing comments from Micheal Harbler and Valerio De Carolis, I am
> > still quite concerned about the choice of DDS.   At issue is
> responsiveness,
> > vitality, community. A perusal of the DDS code repositories show that the
> > are almost stagnant, with OSRF already being the single largest
> contributor
> > to them. This belies the idea of leaving "networking to the experts": if
> > OSRF becomes the principle user and lead maintainer for DDS, then its not
> > leveraging a community of knowledgeable experts. It could be a manpower
> > sink, rather than a benefit.
> >
> > The dig w.r.t corba is real: perhaps it took a few decades for corba to
> > become usable; the fact remains its not much used (I feel responsible for
> > the one exception: having goaded the gimp/gtk/gnome foundation into
> using it
> > 15-20 years ago, for which I am sincerely sorry. ).
> >
> > Its important to understand why this is the case: its because OMG does
> not
> > use a community process or an RFC-style process. This is why its products
> > are moribund.  Compare this to the vitality seen in the IETF, or, closer
> to
> > home, the zeromq RFC process.  The community process has worked well over
> > these decades; abandoning it for a core technology component seems
> > foolhardy.
> >
> > -- Linas
> >
> >
> >
> > On Tue, Sep 29, 2015 at 5:38 PM, Bill Morris via ros-users
> > <ros-users at lists.ros.org> wrote:
> >>
> >> Why are these goals (transport/build system) dependent on each other?
> >> Doing ROS1.5 as an interim release seems like lower risk and less work.
> >>
> >> On 09/29/2015 05:17 PM, Mike Purvis via ros-users wrote:
> >> >> Note here that all the goals that OSRF presents are perfectly
> >> >> achievable
> >> >> using a different strategy: ROS1.5. ROS1.5 means building nodes that
> >> >> talk
> >> >> via the ROS1 protocol, but are built using ROS2 infrastructure and
> >> >> libraries.
> >> >
> >> > Another view of "ROS1.5" would be where APIs (especially the C++ API)
> >> > are
> >> > maintained even as the underlying transport and serialization is
> changed
> >> > around, an improved node/nodelet/launch scheme is developed, etc.
> >> >
> >> > I support the DDS direction, but it does seem to be an all-or-nothing
> >> > affair, and that's one of the biggest bummers about it.
> >> >
> >> > M.
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > ros-users mailing list
> >> > ros-users at lists.ros.org
> >> > http://lists.ros.org/mailman/listinfo/ros-users
> >>
> >> _______________________________________________
> >> ros-users mailing list
> >> ros-users at lists.ros.org
> >> http://lists.ros.org/mailman/listinfo/ros-users
> >
> >
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users at lists.ros.org
> > http://lists.ros.org/mailman/listinfo/ros-users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20150930/fca36c43/attachment.html>