Lack of a velodyne release

The velodyne packages are not quite orphaned, but there has not been a release in over 3 years. This means that there is no binary release for Kinetic, and the binary release for Indigo does not support the VLP-16 sensor.

The only way to use a modern ROS distribution or to get the latest sensor support on Indigo is to compile from source.

This has generated several questions on ROS Answers where users try to compile the source:

The developer continues to respond to issues and merge pull requests, but the latest release was 1.2.0 in Indigo on August 6th 2014, over 3 years ago.
https://github.com/ros-drivers/velodyne/tree/velodyne-1.2.0

Many users are requesting these releases:
https://github.com/ros-drivers/velodyne/issues/93
https://github.com/ros-drivers/velodyne/issues/59

So, what can be done? I am bringing this to the attention of the larger ROS community because discussion on the issue tracker has not worked.

TLDR; The velodyne packages are somewhat actively developed, but haven’t been released in over 3 years. What can be done?

1 Like

Hi,

We had same problem on other packages and have discussed sometimes ago.

Best/Ideal solution is to find other maintainer who take care of release, and according to the discussion above, if we can not find maintainer, the package should be disappeared from newer distro. But, I personally think that is not a good approach. I think velodyne package is worth continue using on kinetic, even if no-one volunteered to release this aver 3 years.

So currently we’re discussing the new way of solve this issue, having a team of “release-maintainer” who only take care of releasing software to new distro(, without judging if the device is actually works on new distro or not), and I believe @gbiggs is writing the draft of this procedure. So let’s wait for his update :wink:

@joq I assume the previous posts refer to you since you have been the only GitHub user being active on the repository. Maybe you can clarify what the status is, why there are no new releases, and if you would like someone else take care of releasing the package.

If @joq doesn’t have the time to do the binary releases for the supported distros but someone else is willing to take that on, perhaps this package is a good test case for having a separate releaser from the maintainer of the source? That would help us find out if this approach can work where there are the volunteers available.

1 Like

There’s been a parallel discussion about this on ros-sig-drivers: Velodyne Driver Maintenance

In short, @joq agreed to let Joshua Whitley share maintainership.

I frequently hear people complaining that they don’t have time to do the binary releases. I always find that a bit odd: In my experience, running the catkin_generate_changelog, catkin_prepare_release, bloom-release commands takes up maybe 1% of the time in maintaining a package. The remaining 99% is spent reviewing, testing, merging and iterating on pull requests, tracking down issues, porting to new distros, responding to issues, fixing bugs, making sure that the package correctly builds on the buildfarm and fixing bugs if it doesn’t. Does it really make a maintainer’s job that much easier if somebody else takes over the binary release part? And what happens when nobody feels responsible for the remaining 99% of the work?

Just trying to understand.

I always find that a bit odd: In my experience, running the catkin_generate_changelog, catkin_prepare_release, bloom-release commands takes up maybe 1% of the time in maintaining a package.

I’m completely agree on that, but it is true that a lot of maintainer feel it is hard to do release job. Maybe they’re toooo busy or more interested in other projects.

Does it really make a maintainer’s job that much easier if somebody else takes over the binary release part?

Main purpose of releasing deb binary from other people is not aiming to reduce original maintainer’s job, but to help users waiting for deb package for newer distro, like @kmhallen.

And what happens when nobody feels responsible for the remaining 99% of the work?

Of course, that’s a big problem. But I’m afraid users waiting for deb packages could not wait until we find solution of this problem, and afraid that many people disappointed to see , for examples, there is no easy way (without source compile) to use velodrome driver on the ROS system.

So

  1. Releasing deb for new distro helps users who willing to use existing packages on their new machine.
  2. Maintaining source tree helps users who willing to use new features or fixed version of the software

I agree we need to take an effort to find/participate maintainer who responsible of good packages, but at the same time, I feel that we want to find good solution to help users just waiting for existing package on new distro. That’s could be solve just a 1% of time of us.

Has anyone given Joshua Whitley write access to https://github.com/ros-drivers/velodyne.git and https://github.com/ros-drivers-gbp/velodyne-release.git ? I know this hasn’t happened as of Friday.

I don’t know what you were looking at. Both Joshua and Mike Purvis are members of the velodyne_maintainers team with admin access to both those repositories.

For those who are wondering, I am getting old and was not in good health most of last year. I am feeling better now and able to keep up with some ROS activities. But, I am not getting younger, and would gladly turn over other packages to more-active maintainers.

Jack, everything seems fine on the Velodyne repository. Josh made a binary release in November, and development seems active with steady commits. Thank you for transitioning maintainership.

1 Like