Hi guys,
I would like to suggest to reorganise the Orocos transports sources. For
the moment, the sources are to be managed in one single repository. This
is not very convenient to manage the dependencies and configuration of
each transport.
I would suggest to create a new git project called orocos-transports and
then create a git repository for each transport. It would allow to
manage more easily each transport, for instance by creating a
manifest.xml file for each of them.
For the moment, the only transport under development in 'transports' is
'yarp', but maybe 'ros', 'mqueue' or others could join this
orocos-transports project.
Do you agree on this proposition?
Charles.
Organization of the Orocos transports
On Wed, May 18, 2011 at 11:39 AM, Charles Lesire-Cabaniols
<Charles [dot] Lesire [..] ...> wrote:
> Hi guys,
>
> I would like to suggest to reorganise the Orocos transports sources. For
> the moment, the sources are to be managed in one single repository. This
> is not very convenient to manage the dependencies and configuration of
> each transport.
>
> I would suggest to create a new git project called orocos-transports and
> then create a git repository for each transport. It would allow to
> manage more easily each transport, for instance by creating a
> manifest.xml file for each of them.
I don't think it's a good restriction to have only one
package/manifest.xml per repository. If this restriction is the
motivation to split transports across multiple repositories, it's a
weak one. Version control and package management should be orthogonal:
have one package consist of multiple repositories or have one
repository containing multiple packages.
>
> For the moment, the only transport under development in 'transports' is
> 'yarp', but maybe 'ros', 'mqueue' or others could join this
> orocos-transports project.
>
> Do you agree on this proposition?
I don't object it since I'm not the maintainer of these transports
anyway. I think repositories should be more structured on a
maintainer/release coordination basis than on a 'module' basis. Look
at the almighty linux kernel where an enormous amount of unrelated
modules are put in a single repository. But they are released as a
single, consistent set, which makes things a lot easier for the end
user.
The ros transport is indeed a separate repository, but it also
contains the Orocos toolchain through git submodules. I'm not a fan of
this approach either, although it does provide consistent versions for
ROS users, so breaking away from this is not that high on the agenda
either.
Peter
Organization of the Orocos transports
On 05/19/2011 10:44 PM, Peter Soetens wrote:
> On Wed, May 18, 2011 at 11:39 AM, Charles Lesire-Cabaniols
>> I would like to suggest to reorganise the Orocos transports sources. For
>> the moment, the sources are to be managed in one single repository. This
>> is not very convenient to manage the dependencies and configuration of
>> each transport.
>>
>> I would suggest to create a new git project called orocos-transports and
>> then create a git repository for each transport. It would allow to
>> manage more easily each transport, for instance by creating a
>> manifest.xml file for each of them.
>
> I don't think it's a good restriction to have only one
> package/manifest.xml per repository.
While, from a tooling point of view, I kind of agree (and autoproj does
have this limitation), I wholeheartedly disagree from an organisational
point of view.
If two packages are not deeply tied together, they have no business
being in the same repository. The hassle of handling the resulting bunch
of repositories should be handled by the tooling, not worked around by
dumping a lot of loosely related things together.
I had a look at ros stack for "motion planning": it contains three BIG
libraries, which in the end would lead (in the git world) to having all
of that code on the build tree even if unused. Nice when you check out
everything and want to have an overview of what is being used on your
system. The more critical one is "navigation_experimental", which
basically contains a lot of navigation-related-things.
And that's why would happen here: YARP and ROS transports have nothing
in common. They go in the same category, that's true, but that's their
only common point. Most likely, people won't use YARP if they use ROS
and vice-versa.
Sylvain
Organization of the Orocos transports
On Friday 20 May 2011 09:37:29 Sylvain Joyeux wrote:
> On 05/19/2011 10:44 PM, Peter Soetens wrote:
> > On Wed, May 18, 2011 at 11:39 AM, Charles Lesire-Cabaniols
> >
> >> I would like to suggest to reorganise the Orocos transports sources. For
> >> the moment, the sources are to be managed in one single repository. This
> >> is not very convenient to manage the dependencies and configuration of
> >> each transport.
> >>
> >> I would suggest to create a new git project called orocos-transports and
> >> then create a git repository for each transport. It would allow to
> >> manage more easily each transport, for instance by creating a
> >> manifest.xml file for each of them.
> >
> > I don't think it's a good restriction to have only one
> > package/manifest.xml per repository.
>
> While, from a tooling point of view, I kind of agree (and autoproj does
> have this limitation), I wholeheartedly disagree from an organisational
> point of view.
>
> If two packages are not deeply tied together, they have no business
> being in the same repository. The hassle of handling the resulting bunch
> of repositories should be handled by the tooling, not worked around by
> dumping a lot of loosely related things together.
We agree here, the tools shouldn't enforce this, it's a dev/maintainer
decision. If you prefer to maintain 50 git repositories instead of 5, that's
your decision. Keep an eye though on the portability of the tools, ie, usable
on different platforms. Depending too much on them downsizes the application
area.
>
> I had a look at ros stack for "motion planning": it contains three BIG
> libraries, which in the end would lead (in the git world) to having all
> of that code on the build tree even if unused.
It wouldn't be build. It would just sit there, until a specific package is
being built that depends on one of these libraries, then that library is built
too.
> Nice when you check out
> everything and want to have an overview of what is being used on your
> system. The more critical one is "navigation_experimental", which
> basically contains a lot of navigation-related-things.
Still, users find it much easier if they only need to download/manage a few
sources than tons of them.
>
> And that's why would happen here: YARP and ROS transports have nothing
> in common. They go in the same category, that's true, but that's their
> only common point. Most likely, people won't use YARP if they use ROS
> and vice-versa.
You knew it wasn't true when you wrote that :-) There are counter examples on
this very list :-) Put I still agree with your point: different maintainers,
unrelated code: different repositories.
Peter
Organization of the Orocos transports
On 05/20/2011 09:59 AM, Peter Soetens wrote:
>> Nice when you check out
>> everything and want to have an overview of what is being used on your
>> system. The more critical one is "navigation_experimental", which
>> basically contains a lot of navigation-related-things.
>
> Still, users find it much easier if they only need to download/manage a few
> sources than tons of them.
Again, if the tooling does it for them, I see that as a moot point.
Another thing: with git, you can "gather" repositories together using
submodules (i.e. you can make both crowds happy *if* you split your
packages in the first place). But you can't do it the other way around.
Organization of the Orocos transports
On 05/20/2011 09:59 AM, Peter Soetens wrote:
>> And that's why would happen here: YARP and ROS transports have nothing
>> in common. They go in the same category, that's true, but that's their
>> only common point. Most likely, people won't use YARP if they use ROS
>> and vice-versa.
>
> You knew it wasn't true when you wrote that :-)
I know it is true, simply because there are no marshalling generators
that target both ROS and YARP (unless I missed something)
Who is doing ROS + YARP by the way ?
Organization of the Orocos transports
On Friday 20 May 2011 10:01:27 Sylvain Joyeux wrote:
> On 05/20/2011 09:59 AM, Peter Soetens wrote:
> >> And that's why would happen here: YARP and ROS transports have nothing
> >> in common. They go in the same category, that's true, but that's their
> >> only common point. Most likely, people won't use YARP if they use ROS
> >> and vice-versa.
> >
> > You knew it wasn't true when you wrote that :-)
>
> I know it is true, simply because there are no marshalling generators
> that target both ROS and YARP (unless I missed something)
>
> Who is doing ROS + YARP by the way ?
I believe Laas in Toulouse is. YARP is used as 'simple' protocol to talk to
3rd party software from Orocos. If you have some ROS node and some YARP
program talking to an Orocos component, you clearly are using both transports.
It's used for bridging to 3rd party software that only talks one protocol, ie,
how all these other frameworks work.
Peter
Organization of the Orocos transports
On 19/05/2011 22:44, Peter Soetens wrote:
> On Wed, May 18, 2011 at 11:39 AM, Charles Lesire-Cabaniols
> <Charles [dot] Lesire [..] ...> wrote:
>> Hi guys,
>>
>> I would like to suggest to reorganise the Orocos transports sources. For
>> the moment, the sources are to be managed in one single repository. This
>> is not very convenient to manage the dependencies and configuration of
>> each transport.
>>
>> I would suggest to create a new git project called orocos-transports and
>> then create a git repository for each transport. It would allow to
>> manage more easily each transport, for instance by creating a
>> manifest.xml file for each of them.
> I don't think it's a good restriction to have only one
> package/manifest.xml per repository. If this restriction is the
> motivation to split transports across multiple repositories, it's a
> weak one. Version control and package management should be orthogonal:
> have one package consist of multiple repositories or have one
> repository containing multiple packages.
>
>> For the moment, the only transport under development in 'transports' is
>> 'yarp', but maybe 'ros', 'mqueue' or others could join this
>> orocos-transports project.
>>
>> Do you agree on this proposition?
> I don't object it since I'm not the maintainer of these transports
> anyway. I think repositories should be more structured on a
> maintainer/release coordination basis than on a 'module' basis. Look
> at the almighty linux kernel where an enormous amount of unrelated
> modules are put in a single repository. But they are released as a
> single, consistent set, which makes things a lot easier for the end
> user.
You're right, sure. And I think that maintaining the Orocos transports
will be far away more easy if we separate them into different
repositories. First because the developers will generally be different
for each transport.
Second because each transport will have specific dependencies (such as
Yarp for the Yarp transport), that may induce some specific releases.
And it will also be more clear to users to identify which transports are
available, and how to get/install them.
> The ros transport is indeed a separate repository, but it also
> contains the Orocos toolchain through git submodules. I'm not a fan of
> this approach either, although it does provide consistent versions for
> ROS users, so breaking away from this is not that high on the agenda
> either.
>
> Peter
Do you know how I could transfer the ownership of the
orocos-communication gitorious project to the orocos-maintainers team?
Charles.
Organization of the Orocos transports
On 05/20/2011 07:52 AM, Charles Lesire-Cabaniols wrote:
> Do you know how I could transfer the ownership of the
> orocos-communication gitorious project to the orocos-maintainers team?
Just did a quick test. I have a "Transfer ownership to group" at the
bottom of the project edit page.
I.e.
go on the project page
click "Edit Project"
Go at the bottom
If you don't have the combo box, I don't know why. Send a support
request to the gitorious guys.
Sylvain
Organization of the Orocos transports
On 20/05/2011 09:59, Sylvain Joyeux wrote:
> On 05/20/2011 07:52 AM, Charles Lesire-Cabaniols wrote:
>> Do you know how I could transfer the ownership of the
>> orocos-communication gitorious project to the orocos-maintainers team?
> Just did a quick test. I have a "Transfer ownership to group" at the
> bottom of the project edit page.
>
> I.e.
>
> go on the project page
> click "Edit Project"
> Go at the bottom
>
> If you don't have the combo box, I don't know why. Send a support
> request to the gitorious guys.
>
> Sylvain
I have this "Transfer" field, but I cannot select any team. Maybe only
team maintainers can.
Charles.
Organization of the Orocos transports
Hi devs,
I have released the Yarp transport last week, that is hosted on the "Orocos
Communication Layer" project on gitorious :
http://gitorious.org/orocos-communication
This project is the place where all Orocos communication-related packages
should go, so please, feel free to add you own repository.
The project has its own package_set for autoproj.
Is anybody still using the 'transports' repository on orocos-toolchain? I
guess no, and without any answer before Wednesday, I propose to delete it.
Organization of the Orocos transports
On Monday 11 July 2011 09:17:13 Charles Lesire-Cabaniols wrote:
> Hi devs,
>
> I have released the Yarp transport last week, that is hosted on the "Orocos
> Communication Layer" project on gitorious :
> http://gitorious.org/orocos-communication
>
> This project is the place where all Orocos communication-related packages
> should go, so please, feel free to add you own repository.
>
> The project has its own package_set for autoproj.
>
> Is anybody still using the 'transports' repository on orocos-toolchain? I
> guess no, and without any answer before Wednesday, I propose to delete it.
Go ahead.
Peter
Organization of the Orocos transports
On Friday 20 May 2011 07:52:24 Charles Lesire-Cabaniols wrote:
> On 19/05/2011 22:44, Peter Soetens wrote:
> > On Wed, May 18, 2011 at 11:39 AM, Charles Lesire-Cabaniols
> >
> > <Charles [dot] Lesire [..] ...> wrote:
> >> Hi guys,
> >>
> >> I would like to suggest to reorganise the Orocos transports sources. For
> >> the moment, the sources are to be managed in one single repository. This
> >> is not very convenient to manage the dependencies and configuration of
> >> each transport.
> >>
> >> I would suggest to create a new git project called orocos-transports and
> >> then create a git repository for each transport. It would allow to
> >> manage more easily each transport, for instance by creating a
> >> manifest.xml file for each of them.
> >
> > I don't think it's a good restriction to have only one
> > package/manifest.xml per repository. If this restriction is the
> > motivation to split transports across multiple repositories, it's a
> > weak one. Version control and package management should be orthogonal:
> > have one package consist of multiple repositories or have one
> > repository containing multiple packages.
> >
> >> For the moment, the only transport under development in 'transports' is
> >> 'yarp', but maybe 'ros', 'mqueue' or others could join this
> >> orocos-transports project.
> >>
> >> Do you agree on this proposition?
> >
> > I don't object it since I'm not the maintainer of these transports
> > anyway. I think repositories should be more structured on a
> > maintainer/release coordination basis than on a 'module' basis. Look
> > at the almighty linux kernel where an enormous amount of unrelated
> > modules are put in a single repository. But they are released as a
> > single, consistent set, which makes things a lot easier for the end
> > user.
>
> You're right, sure. And I think that maintaining the Orocos transports
> will be far away more easy if we separate them into different
> repositories. First because the developers will generally be different
> for each transport.
> Second because each transport will have specific dependencies (such as
> Yarp for the Yarp transport), that may induce some specific releases.
> And it will also be more clear to users to identify which transports are
> available, and how to get/install them.
>
> > The ros transport is indeed a separate repository, but it also
> > contains the Orocos toolchain through git submodules. I'm not a fan of
> > this approach either, although it does provide consistent versions for
> > ROS users, so breaking away from this is not that high on the agenda
> > either.
> >
> > Peter
>
> Do you know how I could transfer the ownership of the
> orocos-communication gitorious project to the orocos-maintainers team?
It's not possible. You created it, you own it :-) What you can do is invite us
too and give us admin rights.
Peter
Organization of the Orocos transports
On 05/20/2011 09:42 AM, Peter Soetens wrote:
>> Do you know how I could transfer the ownership of the
>> orocos-communication gitorious project to the orocos-maintainers team?
>
> It's not possible. You created it, you own it :-) What you can do is invite us
> too and give us admin rights.
??? As far as I remember it is indeed possible (but you can do it only once)
I wonder if he does not have to be admin on orocos-maintainers to do
that ...
Organization of the Orocos transports
On Wed, 18 May 2011, Charles Lesire-Cabaniols wrote:
> Hi guys,
>
> I would like to suggest to reorganise the Orocos transports sources. For
> the moment, the sources are to be managed in one single repository. This
> is not very convenient to manage the dependencies and configuration of
> each transport.
>
> I would suggest to create a new git project called orocos-transports and
> then create a git repository for each transport. It would allow to
> manage more easily each transport, for instance by creating a
> manifest.xml file for each of them.
>
> For the moment, the only transport under development in 'transports' is
> 'yarp', but maybe 'ros', 'mqueue' or others could join this
> orocos-transports project.
>
> Do you agree on this proposition?
The more (justified) decoupling, the better:-) So, in principle I agree.
But I would change the name "transport" to "Communication" (in order to
start harmonizing nomenclature towards the "5Cs", whenever possible.
> Charles.
Herman
Organization of the Orocos transports
On May 18, 2011, at 06:58 , Herman Bruyninckx wrote:
> On Wed, 18 May 2011, Charles Lesire-Cabaniols wrote:
>
>> Hi guys,
>>
>> I would like to suggest to reorganise the Orocos transports sources. For
>> the moment, the sources are to be managed in one single repository. This
>> is not very convenient to manage the dependencies and configuration of
>> each transport.
>>
>> I would suggest to create a new git project called orocos-transports and
>> then create a git repository for each transport. It would allow to
>> manage more easily each transport, for instance by creating a
>> manifest.xml file for each of them.
>>
>> For the moment, the only transport under development in 'transports' is
>> 'yarp', but maybe 'ros', 'mqueue' or others could join this
>> orocos-transports project.
>>
>> Do you agree on this proposition?
+1
> The more (justified) decoupling, the better:-) So, in principle I agree.
> But I would change the name "transport" to "Communication" (in order to
> start harmonizing nomenclature towards the "5Cs", whenever possible.
+1
I find that getting people to understand the 4C's (or 5) really helps with good system design.
S
Organization of the Orocos transports
On 18/05/2011 13:06, S Roderick wrote:
> On May 18, 2011, at 06:58 , Herman Bruyninckx wrote:
>
>> On Wed, 18 May 2011, Charles Lesire-Cabaniols wrote:
>>
>>> Hi guys,
>>>
>>> I would like to suggest to reorganise the Orocos transports sources. For
>>> the moment, the sources are to be managed in one single repository. This
>>> is not very convenient to manage the dependencies and configuration of
>>> each transport.
>>>
>>> I would suggest to create a new git project called orocos-transports and
>>> then create a git repository for each transport. It would allow to
>>> manage more easily each transport, for instance by creating a
>>> manifest.xml file for each of them.
>>>
>>> For the moment, the only transport under development in 'transports' is
>>> 'yarp', but maybe 'ros', 'mqueue' or others could join this
>>> orocos-transports project.
>>>
>>> Do you agree on this proposition?
> +1
>
>> The more (justified) decoupling, the better:-) So, in principle I agree.
>> But I would change the name "transport" to "Communication" (in order to
>> start harmonizing nomenclature towards the "5Cs", whenever possible.
> +1
>
> I find that getting people to understand the 4C's (or 5) really helps with good system design.
> S
>
Ok, here it is:
https://gitorious.org/orocos-communication
I have created the 'yarp-transport' repository.
I just can't transfer the ownership to the orocos-maintainers group...
Charles.
Organization of the Orocos transports
On May 19, 2011, at 04:01 , Charles Lesire-Cabaniols wrote:
> On 18/05/2011 13:06, S Roderick wrote:
>> On May 18, 2011, at 06:58 , Herman Bruyninckx wrote:
>>
>>> On Wed, 18 May 2011, Charles Lesire-Cabaniols wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I would like to suggest to reorganise the Orocos transports sources. For
>>>> the moment, the sources are to be managed in one single repository. This
>>>> is not very convenient to manage the dependencies and configuration of
>>>> each transport.
>>>>
>>>> I would suggest to create a new git project called orocos-transports and
>>>> then create a git repository for each transport. It would allow to
>>>> manage more easily each transport, for instance by creating a
>>>> manifest.xml file for each of them.
>>>>
>>>> For the moment, the only transport under development in 'transports' is
>>>> 'yarp', but maybe 'ros', 'mqueue' or others could join this
>>>> orocos-transports project.
>>>>
>>>> Do you agree on this proposition?
>> +1
>>
>>> The more (justified) decoupling, the better:-) So, in principle I agree.
>>> But I would change the name "transport" to "Communication" (in order to
>>> start harmonizing nomenclature towards the "5Cs", whenever possible.
>> +1
>>
>> I find that getting people to understand the 4C's (or 5) really helps with good system design.
>> S
>>
>
> Ok, here it is:
> https://gitorious.org/orocos-communication
>
> I have created the 'yarp-transport' repository.
>
> I just can't transfer the ownership to the orocos-maintainers group...
>
> Charles.
What will happen with "orocos-toolchain/transports"?
S
Organization of the Orocos transports
On 19/05/2011 10:54, S Roderick wrote:
> On May 19, 2011, at 04:01 , Charles Lesire-Cabaniols wrote:
>
>> On 18/05/2011 13:06, S Roderick wrote:
>>> On May 18, 2011, at 06:58 , Herman Bruyninckx wrote:
>>>
>>>> On Wed, 18 May 2011, Charles Lesire-Cabaniols wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I would like to suggest to reorganise the Orocos transports sources. For
>>>>> the moment, the sources are to be managed in one single repository. This
>>>>> is not very convenient to manage the dependencies and configuration of
>>>>> each transport.
>>>>>
>>>>> I would suggest to create a new git project called orocos-transports and
>>>>> then create a git repository for each transport. It would allow to
>>>>> manage more easily each transport, for instance by creating a
>>>>> manifest.xml file for each of them.
>>>>>
>>>>> For the moment, the only transport under development in 'transports' is
>>>>> 'yarp', but maybe 'ros', 'mqueue' or others could join this
>>>>> orocos-transports project.
>>>>>
>>>>> Do you agree on this proposition?
>>> +1
>>>
>>>> The more (justified) decoupling, the better:-) So, in principle I agree.
>>>> But I would change the name "transport" to "Communication" (in order to
>>>> start harmonizing nomenclature towards the "5Cs", whenever possible.
>>> +1
>>>
>>> I find that getting people to understand the 4C's (or 5) really helps with good system design.
>>> S
>>>
>> Ok, here it is:
>> https://gitorious.org/orocos-communication
>>
>> I have created the 'yarp-transport' repository.
>>
>> I just can't transfer the ownership to the orocos-maintainers group...
>>
>> Charles.
> What will happen with "orocos-toolchain/transports"?
> S
>
I guess it will just be removed ; currently it just hosts the yarp
transport I am developing...
Organization of the Orocos transports
Am 18.05.11 11:39, schrieb Charles Lesire-Cabaniols:
> Hi guys,
>
> I would like to suggest to reorganise the Orocos transports sources. For
> the moment, the sources are to be managed in one single repository. This
> is not very convenient to manage the dependencies and configuration of
> each transport.
>
> I would suggest to create a new git project called orocos-transports and
> then create a git repository for each transport. It would allow to
> manage more easily each transport, for instance by creating a
> manifest.xml file for each of them.
>
> For the moment, the only transport under development in 'transports' is
> 'yarp', but maybe 'ros', 'mqueue' or others could join this
> orocos-transports project.
>
> Do you agree on this proposition?
>
> Charles.
>
+1
We recently started to work on a zeromq transport and a common repo
could help to organize them more.
Nico
Organization of the Orocos transports
On 05/18/2011 11:39 AM, Charles Lesire-Cabaniols wrote:
> Hi guys,
>
> I would like to suggest to reorganise the Orocos transports sources. For
> the moment, the sources are to be managed in one single repository. This
> is not very convenient to manage the dependencies and configuration of
> each transport.
>
> I would suggest to create a new git project called orocos-transports and
> then create a git repository for each transport. It would allow to
> manage more easily each transport, for instance by creating a
> manifest.xml file for each of them.
>
> For the moment, the only transport under development in 'transports' is
> 'yarp', but maybe 'ros', 'mqueue' or others could join this
> orocos-transports project.
>
> Do you agree on this proposition?
+1
Sylvain
Organization of the Orocos transports
+1