search

rock-core / package_set

Package definition for autoproj, to build all the packages that form the core of Rock, the Robot Construction Kit
http://rock-robotics.org/documentation/
0 stars 24 forks source link

hard-fork orocos-toolchain packages we need for rock #203

Closed doudou closed 2 years ago

doudou commented 2 years ago

I've been unable to reach anyone on the orocos side for 2-3 years now to discuss the future of ... anything really. Even RTT. I think it's time to stop bothering.

planthaber commented 2 years ago

I'm not against this but i don't get:

  1. The reason to fork it at all (you had write access in orocos-toolchain too, right?)
  2. Why a hard-fork if the code shares the same origin I don't see a reason to remove the linkage?
doudou commented 2 years ago

Good questions

  1. because there are still people using the orocos toolchain, who therefore happen to depend on the typelib version in orocos-toolchain/typelib. As I don't plan to support this use case (which was always not very well working in the first place), I don't want to work in the orocos toolchain repo. Additionally, this fork makes it clear that I consider that typelib is a rock-core project (which, in hindsight, it always was) maintained by Rock developers.
  2. because without removing the linkage, new pull requests and issues end up in the original repository, which creates a lot of confusion.
doudou commented 2 years ago

If there is an agreement of principle, I'll change this pull request to hard-fork all the packages that are relevant to Rock, that is, in addition to rtt (which is already forked) and typelib:

@planthaber, thoughts ? Are you the right person to discuss this with at DFKI ? If not, can you point me to that person ?

planthaber commented 2 years ago

@planthaber, thoughts ? Are you the right person to discuss this with at DFKI ? If not, can you point me to that person ?

I'm fine with this, and yes, i am the right person now.

planthaber commented 2 years ago

What do you think of renaming the packages to match the folder names?

e.g. orogen->tools/orogen and add metapackage to match also the old name?

This would make stuff like 'amake tools/orogen' actually work instead of amake orogen

We could remove the moving of the packages here: https://github.com/rock-core/package_set/blob/master/01import_orocos_toolchain.autobuild#L51

doudou commented 2 years ago

I want to go slow on this, but that's on my list, yes.

For me, the cleanup steps are: