Adding new repository for indexing: acado

[Andor233]

No description provided.

[clalancette]

In all previous ROS distributions, this package was released from the upstream repository, namely https://github.com/tud-cor/acado.git . Can you please work with @RonaldEnsing to get this released from that repository?

[Andor233]

I will create a pull request

[Andor233]

@clalancette what's your opinion
tud-cor/acado#1

[gavanderhoorn]

So we're not actually using Acado any more at CoR (or at least not with ROS), so we don't have an interest in maintaining the ROS release.

The easy way out would be to just accept the PR here, update the release and source repository.

And then wait for the next iteration of this process, where someone else wants to get an updated release of Acado into ROS, but @Andor233 is not around any more for whatever reason.

To improve continuity and make maintenance of such third-party releases a shared effort, would it perhaps be an idea to create a ros-thirdparty-releases organisation where release repositories for these kinds of packages would be hosted? The owners of that organisation would then always be able to grant access to new maintainers.

I realise this adds to the ever increasing maintenance overhead of all these packages, but might actually be worth it.

(and in this case I believe a new source repository is not needed: the patch to the CMakeLists.txt and the addition of the manifest could be part of the release repository, with the release simply tracking upstream's master).

[RonaldEnsing]

I agree with @gavanderhoorn that something like a ros-thirdparty-releases may be preferred over the current process.

[Andor233]

I agree too.
Actually, there is many of this kind repo in ROS, if we can find some way to add a package.xml and modify cmakelists.txt which like vcpkg is doing, I think everything will be better. It can be published to every ROS version (because these repos are ROS independent) rather than I need to make a new repo and use bloom to do release manually. Everything will be more automatic.

vcpkg is a good example I think.

[gavanderhoorn]

if we can find some way to add a package.xml and modify cmakelists.txt which like vcpkg is doing, I think everything will be better.

you should be able to add those as patches in your release repository.

It can be published to every ROS version (because these repos are ROS independent) rather than I need to make a new repo and use bloom to do release manually.

just a note: this is not what I'm suggesting, and would also not be a desirable situation.

Tbh the packaging situation on Windows is not something I believe we should try to duplicate on Linux.

[clalancette]

(and in this case I believe a new source repository is not needed: the patch to the CMakeLists.txt and the addition of the manifest could be part of the release repository, with the release simply tracking upstream's master).

I think this is the easiest path forward. If we could simply track https://github.com/acado/acado and patch in the package.xml in the release repository, that would be a lot better than what we have now. I guess it will still need a new release repository (since it seems like CoR isn't willing to host anymore), but that is a lot easier.

[wjwwood]

@clalancette what should we do here? Wait for an update to the pull request or close it?

[Andor233]

if we can find some way to add a package.xml and modify cmakelists.txt which like vcpkg is doing, I think everything will be better.

you should be able to add those as patches in your release repository.

It can be published to every ROS version (because these repos are ROS independent) rather than I need to make a new repo and use bloom to do release manually.

just a note: this is not what I'm suggesting, and would also not be a desirable situation.

Tbh the packaging situation on Windows is not something I believe we should try to duplicate on Linux.

Why not? I mean all the ROS independent package, the only thing changed is the system version( like Glibc, GCC) It should be all the same for every ROS version.

[sloretz]

I'm not familiar with how vcpkg does things, but it sounds like there's consensus on needing to modify the CMakeLists.txt and add a package.xml. It looks like the preferred way to do this is by patching it in the release repo rather than forking. There's some documentation on how to do that here.

http://wiki.ros.org/bloom/Tutorials/ReleaseThirdParty#Modifying_the_Release_Repository

@Andor233 I think I can make a release repo for acado on the ros-gbp org if you'd be willing to make a release from there.

[gavanderhoorn]

Some days ago #28441 was merged, which introduced an acado_vendor package.

Source repository: autowarefoundation/autoware.auto/acado_vendor.

It was only released for ROS 2 though.

[jacobperron]

Funnily enough, acado_vendor just pulls in a fork that contains a package.xml and modifies the CMakeLists.txt

https://gitlab.com/autowarefoundation/autoware.auto/acado_vendor/-/blob/main/CMakeLists.txt#L19

I'm not sure how feasible it is, but I think it would be better if the vendor package could pull in the original repository directly and apply necessary patches there (or just use a patched release repository as suggested above).

[clalancette]

There's been no motion on this for a while, so I'm going to close this out. I think the way forward here is a new release repository that patches in the package.xml and CMakeLists.txt as necessary. Please feel free to request a new release repository from us, and we're happy to create it.