[ros-users] ROS 2.0 Strategy review

[Thibault Kruse]

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
>