Tudelft stable

[Andor233]

No description provided.

[gavanderhoorn]

Thanks for the PR, but I feel some more context would be good.

Afaik, @RonaldEnsing has used this repository to prepare a release of acado on the ROS buildfarm, not really to do any development. Nor are we planning for this repository to become the place for Acado development.

It looks like @RonaldEnsing used a Bloom 3rd party release, meaning only a package.xml was added to what is otherwise a pristine upstream.

I would suggest we figure out a way to make releasing upstream easier, or in a more central place. That way, it would be independent of our use here at CoR.

@RonaldEnsing: your opinion?

[Andor233]

Actually this pr just sync the root acado repo and I just prepare it to release it in ros noetic.
Nothing else are been changed.

[gavanderhoorn]

In that case it would be better to fast-forward master and then rebase tudelft-stable I believe.

But that doesn't solve the question of whether we should keep this fork here (on tud-cor).

[gavanderhoorn]

If all we need to do is add a package.xml and patch the CMakeLists.txt, we might not even need a fork of acado/acado, as such patches could be made part of the release repository instead.

[Andor233]

If all we need to do is add a package.xml and patch the CMakeLists.txt, we might not even need a fork of acado/acado, as such patches could be made part of the release repository instead.

Yeah maybe you are right but where to store the package.xml?

[gavanderhoorn]

I've commented on ros/rosdistro#27907.

[gavanderhoorn]

I don't feel "lugging around" these source and release repositories is a good-thing.

[RonaldEnsing]

Afaik, @RonaldEnsing has used this repository to prepare a release of acado on the ROS buildfarm, not really to do any development. Nor are we planning for this repository to become the place for Acado development.

Yes, this is the case.

It looks like @RonaldEnsing used a Bloom 3rd party release, meaning only a package.xml was added to what is otherwise a pristine upstream.

Yes, indeed.

I would suggest we figure out a way to make releasing upstream easier, or in a more central place. That way, it would be independent of our use here at CoR.

Like you describe here [1]? Yes, that sounds good.

If all we need to do is add a package.xml and patch the CMakeLists.txt, we might not even need a fork of acado/acado, as such patches could be made part of the release repository instead.

Yes, sounds like a good idea to me as well. Only small changes to the repository (CMakeLists.txt and package.xml) were needed for a ROS release. Avoiding the need to fork the upstream acado would be preferred.

[1] ros/rosdistro#27907 (comment)