Open cdondrup opened 7 years ago
Hi Christian, yeap, it does make sense to move frenap to strands_navigation. Feel free to proceed :)
Hi, I am not sure about this, I actually think it makes no sense to keep it in the main branches how about moving it to a deprecated branch? is not in use anymore.
If it is not in use in could indeed be moved to a deprecated or legacy branch. Just a matter of in this repo or in strands_navigation.
I agree it shouldn't be in here. If it end in a "dead" branch, it will effectively be dead. Which is fine, if it's not being used in the future. But if it will be then we should move it somewhere else. But, for now, I'm happy for you to create a "strands-legacy" branch and proceed.
I would like to use fremen for our project (maybe) and noticed that when trying to build it, it depends on
strands_navigation_msgs
. Which means that if I want to build things from source, I have to check out the whole navigation stuff as well including all its dependencies which I don't need.Of course, once there are packages for Kinetic one could install those and be done with it, but I am not sure I can convince everybody to set-up the strands repositories on their machines. Hence, it would be easiest if this otherwise very self-contained repo would not depend on
strands_navigation_msgs
. As far as I can tell, onlyfrenap
depends on those which also creates circular dependencies between the repos as discussed in #13.If it is not too much of a problem, I would suggest moving
frenap
tostrands_navigation
instead. This would solve the circular dependencies issue as far as I can see and would also mean that this repo only relies on officially released packages. Also, I am not sure iffrenap
is supposed to be used withoutstrands_navigation
in the first place.All this is, of course, just a suggestion so please ignore me if it is too much work or you disagree. The workaround is just deleting
frenap
from my local fork so not much of a problem. Just thought I'd share my two cents.