<div dir="ltr">Hi Thibault,<div><br></div><div>For opensplice, I looked at <a href="https://github.com/PrismTech/opensplice/network">https://github.com/PrismTech/opensplice/network</a> 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: <a href="https://github.com/PrismTech/opensplice/graphs/commit-activity">https://github.com/PrismTech/opensplice/graphs/commit-activity</a> Conclusion is that the project is stagnant.</div><div><br></div><div>For <a href="https://github.com/objectcomputing/OpenDDS">https://github.com/objectcomputing/OpenDDS</a> -- I see actually that it is very active: <a href="https://github.com/objectcomputing/OpenDDS/graphs/contributors">https://github.com/objectcomputing/OpenDDS/graphs/contributors</a>  and none of it seems to involve OSRF people.  (Note that <a href="https://www.openhub.net/p/opendds">https://www.openhub.net/p/opendds</a> does not reflect this location; it shows an older svn repo that has gone inactive)</div><div><br></div><div>For eprosima  I see <a href="https://github.com/eProsima/Fast-RTPS">https://github.com/eProsima/Fast-RTPS</a> -- they have other repos, but this seems to be the correct one to look at.  Its shows some activity but few contributors. <a href="https://github.com/eProsima/Fast-RTPS/graphs/contributors">https://github.com/eProsima/Fast-RTPS/graphs/contributors</a> The other eprosima reps seem to be similar.</div><div><br></div><div>In any case, the good news is that they're all on github, which does make this kind of prowling around much much easier.</div><div><br></div><div>-- Linas</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 30, 2015 at 2:53 AM, Thibault Kruse <span dir="ltr"><<a href="mailto:tibokruse@googlemail.com" target="_blank">tibokruse@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Linas,<br>
<br>
Some buildsystem changes are apparently linked to the move to DDS<br>
because OSRF wanted to make the vendor choice configurable, which<br>
required some changes over catkin. However other changes were made<br>
that are not linked to DDS, and with more effort could have been done<br>
in backwards compatible ways. [1]<br>
<br>
I am not sure which "DDS code repositories" you talk about. OMG does<br>
not have an own DDS implementation. Of the open alternatives<br>
OpenSplice seems to have low commit activity, while openDDS and<br>
eProsima seem to have more activity [2, 3, 4]. (Commit statistics can<br>
be misleading for Opensplice because they summarize commits into<br>
public release commits, but even knowing that it seems activity is<br>
low).<br>
Can you point to what you mean?<br>
<br>
regards,<br>
  Thibault<br>
<br>
<br>
<br>
<br>
<br>
[1] <a href="https://groups.google.com/forum/#!topic/ros-sig-ng-ros/gyToaPoiQi4" rel="noreferrer" target="_blank">https://groups.google.com/forum/#!topic/ros-sig-ng-ros/gyToaPoiQi4</a><br>
[2] <a href="https://www.openhub.net/p/opensplice-dds" rel="noreferrer" target="_blank">https://www.openhub.net/p/opensplice-dds</a><br>
[3] <a href="https://www.openhub.net/p/eprosima" rel="noreferrer" target="_blank">https://www.openhub.net/p/eprosima</a><br>
[4] <a href="https://www.openhub.net/p/opendds" rel="noreferrer" target="_blank">https://www.openhub.net/p/opendds</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Sep 30, 2015 at 2:46 AM, Linas Vepstas via ros-users<br>
<<a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a>> wrote:<br>
> Agreed.<br>
><br>
> Incremental, evolutionary changes rolled out on a shorter time frame seems a<br>
> much safer development course.  If there is a reason to couple API changes<br>
> to the build system to the network protocol, I haven't seen it.<br>
><br>
> After seeing comments from Micheal Harbler and Valerio De Carolis, I am<br>
> still quite concerned about the choice of DDS.   At issue is responsiveness,<br>
> vitality, community. A perusal of the DDS code repositories show that the<br>
> are almost stagnant, with OSRF already being the single largest contributor<br>
> to them. This belies the idea of leaving "networking to the experts": if<br>
> OSRF becomes the principle user and lead maintainer for DDS, then its not<br>
> leveraging a community of knowledgeable experts. It could be a manpower<br>
> sink, rather than a benefit.<br>
><br>
> The dig w.r.t corba is real: perhaps it took a few decades for corba to<br>
> become usable; the fact remains its not much used (I feel responsible for<br>
> the one exception: having goaded the gimp/gtk/gnome foundation into using it<br>
> 15-20 years ago, for which I am sincerely sorry. ).<br>
><br>
> Its important to understand why this is the case: its because OMG does not<br>
> use a community process or an RFC-style process. This is why its products<br>
> are moribund.  Compare this to the vitality seen in the IETF, or, closer to<br>
> home, the zeromq RFC process.  The community process has worked well over<br>
> these decades; abandoning it for a core technology component seems<br>
> foolhardy.<br>
><br>
> -- Linas<br>
><br>
><br>
><br>
> On Tue, Sep 29, 2015 at 5:38 PM, Bill Morris via ros-users<br>
> <<a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a>> wrote:<br>
>><br>
>> Why are these goals (transport/build system) dependent on each other?<br>
>> Doing ROS1.5 as an interim release seems like lower risk and less work.<br>
>><br>
>> On 09/29/2015 05:17 PM, Mike Purvis via ros-users wrote:<br>
>> >> Note here that all the goals that OSRF presents are perfectly<br>
>> >> achievable<br>
>> >> using a different strategy: ROS1.5. ROS1.5 means building nodes that<br>
>> >> talk<br>
>> >> via the ROS1 protocol, but are built using ROS2 infrastructure and<br>
>> >> libraries.<br>
>> ><br>
>> > Another view of "ROS1.5" would be where APIs (especially the C++ API)<br>
>> > are<br>
>> > maintained even as the underlying transport and serialization is changed<br>
>> > around, an improved node/nodelet/launch scheme is developed, etc.<br>
>> ><br>
>> > I support the DDS direction, but it does seem to be an all-or-nothing<br>
>> > affair, and that's one of the biggest bummers about it.<br>
>> ><br>
>> > M.<br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > ros-users mailing list<br>
>> > <a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a><br>
>> > <a href="http://lists.ros.org/mailman/listinfo/ros-users" rel="noreferrer" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
>><br>
>> _______________________________________________<br>
>> ros-users mailing list<br>
>> <a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a><br>
>> <a href="http://lists.ros.org/mailman/listinfo/ros-users" rel="noreferrer" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> ros-users mailing list<br>
> <a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a><br>
> <a href="http://lists.ros.org/mailman/listinfo/ros-users" rel="noreferrer" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
><br>
</div></div></blockquote></div><br></div>