Release to ROS1 and ROS2 about apriltag HOT 32 CLOSED

Release requests for kinetic and melodic are pending:

• Kinetic: ros/rosdistro#21221
• Melodic: ros/rosdistro#21220

from apriltag.

I've gone ahead and renamed this repo to apriltag

from apriltag.

I haven't heard back from the ros-gbp org owners whether that would be appropriate. It probably just makes sense to make an apriltag-release repo in this org, that way the permissions are under your control.

Creating a canonical apriltag_ros in this org as well sounds amazing!

from apriltag.

@christianrauch done - ros/rosdistro#21226

from apriltag.

@mkrogius we can close this issue :-)

from apriltag.

@christianrauch are you planning to do this PR? I have master building fine on 18.04/Melodic.

from apriltag.

@rgreid I can do the release. However, I still prefer that the release repository is placed in a public visible place, e.g. https://github.com/AprilRobotics/apriltag-release or https://github.com/ros-gbp/apriltag-release with access by multiple maintainers to prevent that the package gets orphaned in the future.

from apriltag.

Which of those two places would you prefer to host the release repository? I would have a slight preference for hosting in ros-gbp, but if that is more work to set up than I would be happy to make a new repo in the AprilRobotics org.

from apriltag.

I've no preferences. In any case, I would need to get access to that organisation or release repo.

If I recall correctly, the release process requires that the upstream repo has tags that match the version in the package.xml and that the version increments according to the Semantic Versioning.
I originally stated the BSD license. Is this still correct?
Can you update the version, and if necessary the license, in the package.xml?

from apriltag.

Looping in @paulbovbel regarding a ros-gbp release repository.

from apriltag.

To help others, since I had to google it, the requirements for a ROS 'release repo' are here.

@mkrogius one thought might be to rename this repo to apriltag, and then transfer/fork the dmalyuta/apriltags2_ros node repo here, so that we have two repos named consistently:

• https://github.com/AprilRobotics/apriltag
• https://github.com/AprilRobotics/apriltag_ros

As discussed here. Just my two cents!

from apriltag.

I'm happy to rename it. I just need to check there aren't negative effects of renaming a repo

from apriltag.

@mkrogius Github automatically creates redirects so both old and new URLs continue to work.

from apriltag.

Fantastic, thank you. Regarding release repository, @paulbovbel - is it possible to get one within @ros-gbp?

from apriltag.

@mkrogius can you please create a apriltag-release repository here as well if that's okay so the library can be released into ROS? Thank you :)

from apriltag.

Done, and I've added the same collaborators as for apriltag_ros

from apriltag.

Great. Do we need an apriltag_ros-release repo also?

from apriltag.

Yes, good call @rgreid.

Thank you for creating the repository and the invite @mkrogius. As final steps prior to the release, we should decide
(a) to make a new tag 3.0.1 with the latest master as it includes a fix (cf. v3.0.0...master) and increment the version number in package.xml accordingly,
(b) who runs bloom to release it, and
(c) on adding that person to the maintainer emails in package.xml as those emails listed will receive status emails on errors etc. Currently there are:

from apriltag.

@wxmerkt Could you also do a release for ROS dashing?
I would do a dashing release if I get access to the release repo. However, for not having to do yet another patch release just for adding me as maintainer, only you would be notified on dashing release failures. This may not be a problem, since this repo does not depend on ROS packages and if a release on melodic succeeds, it should also succeed for dashing.

from apriltag.

On a related note, should we push apriltag_ros also? The old apriltags2_ros package is currently in rosdistro: https://github.com/ros/rosdistro/blob/master/kinetic/distribution.yaml#L236

from apriltag.

Yes, I was waiting for these pull requests to clear. I am happy to bloom apriltag_ros once we have a apriltag_ros-release repository.

from apriltag.

I created the apriltag_ros-release repo

from apriltag.

Thank you :)

from apriltag.

Pull requests for apriltag_ros to kinetic and melodic are open - note: I haven't removed the original apriltags2_ros release in kinetic.

Kinetic: ros/rosdistro#21348
Melodic: ros/rosdistro#21349

from apriltag.

The release to Kinetic just got reverted amidst build failures. Unfortunately, the buildfarm has some hiccups and I cannot access detailed logs right now - cf. ros/rosdistro#21437

@mkrogius Have you build on ARM before and have you seen the long buildtimes they advise? I don't understand the long buildtimes on amd64, apart from maybe memory limitations.

from apriltag.

@wxmerkt I have come across this issue before with long build times. It seems that anything -O2 and above causes gcc on ARM to take a super long time to build the larger tag families. In theory this should have been fixed with the attribute((optimize("O0"))) on the tag_*_create functions.

I don't know if this fix was ever verified, since for me, the build times are pretty reasonable on my raspberry pi. I would need to spend some more time, maybe later this week to look into this issue more. For now, one option would be to not build the 3 large tag families by default.

Some references:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921256
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920894
For this debian package, the solution by Dima Kogan was to load the tag codes at runtime instead of having them compiled into the binary.

from apriltag.

Thank you, Max - this are great pointers. Is apriltag now part of a debian release? And has the loading-at-runtime fix been upstreamed into this repository?

from apriltag.

I think we might be part of a debian release now, yes. The loading-at-runtime fix was never upstreamed, but that was because we wanted a different implementation of loading at runtime. Since we control the generation of these files, it makes more sense to just directly generate the files to be loaded.

I also think its worth it to try compiling these files with O0, to see if that fixes it (if we had a way to reproduce the issue)

from apriltag.

I've pushed a fix for the compile time issue to the AprilTag repo. The issue was that on older (5.4) versions of gcc, track-vars is very slow: https://stackoverflow.com/questions/2954473/variable-tracking-is-eating-my-compile-time.

I made a pretty minimal change to fix this, instead of specifying "O0" in the attribute, I specify it for the whole file in the build rule (only for the tag*.c files where performance doesn't really matter).

from apriltag.

Thank you for tracking this down and fixing it. Do you mind updating the package.xml version tag to 3.1.1 and adding a new git tag 3.1.1? Then we can do another round of releases for ROS :)

from apriltag.

No problem: https://github.com/AprilRobotics/apriltag/releases/tag/3.1.1

from apriltag.

Thank you - I have made the new release requests.

from apriltag.