ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

New Software Release Announcements

release

#12

“5. Binary releases only” … “releasing binaries on the OSRF build farm isn’t a difficult process”

Just and FYI on that one. The build farm is totally foreign to people like myself who have not done it before. The requisite tutorials / documentation is not sufficient to get many package developers over the fear of messing something up.

Back to the OP, I like the idea - with two points:

  1. Very quickly it will fall apart if it is not well organized and easily searchable. This may mean having some type of recommended template to what should be included in an announcement. e.g. package name, short description, availability, where is can be found, any prerequisites, hardware dependencies, etc.

  2. I’m sure there are users like myself who did an internet search and found “ROS Answers” and never knew of “discourse”. These two entities are very independent - to the point they have separate registrations - and yet they are very symbiotic.


#13

This is a good idea, and I think it’d be a nice way for people to get the word out about software they’re working on.

However, I agree that such a list should encourage posts about software that isn’t released in binary form as well. If someone stumbles across a source package and is interested enough in the project to want a binary release, they can work with the upstream developers to make it happen (especially if the downstream user already versed in the packaging process.) Packaging isn’t difficult, but it is a different skill set, and not everyone is interested in learning it or taking on the additional package maintenance burden. ROS could take a page from Linux distributions here, where the packagers are mostly independent of the software projects, but work with upstream to make the software available.


#14

Coincidentally I was updating a “indexing your package” wiki page where I added a section for encouraging making an announcement, as well as a small template. So obviously +1.

On a related note, to discuss improving the ROS’ already-amazing infrastructure that has helped us (semi-)automate non-coding tasks, I opened some tickets. Ideas behind is that package indexing and package’s wiki page are the keys that help us to find, reach existing packages.


#15
  1. Binary releases only

I understand the points about packaging and they are well made.

Putting that to the side for the moment - I am concerned what may happen if there is no barrier to posting. In their excitement, it may become inundated by posts from devs who may have no serious inclination towards maintenance nor raising it to a reasonable level of usability/quality. Nothing wrong with such exuberance, I like to see that in an open source dev, but it could make it unusable for various groups who need the category. I’ve been running a team for the last three years working on next-gen products, and I would not have had the time to delegate on testing N ‘promising’ releases to find the one that is actually at a point where we’d jump in and contribute/use. As such, my perspective is somewhere in the middle. I imagine the bar would be different for a product team (high) and again for a research lab (low).

For me, packaging was a sign that this is usually maintained, has activity on the issue trackers, has dealt with the small problems like install rules and such. Of course, doesn’t make much sense if packages and source maintainers are separate.

Perhaps we can make use of tags to assist here, e.g. ‘binary-release’, ‘source-release’, ‘developed’, ‘<1.0’, ‘1.x’, and worst case scenario, put a human(s) in the loop to help check tags/veto low-level or plain noisy announcements.


#16

You’re looking for curation, it seems.

As you said, there’s a lot of metrics that can contribute to deciding which packages are well supported and can be relied upon, and which were dumped on github by a grad student 3 months before graduation and will never be touched again. The availability of binary packages is certainly one metric, and may be a reasonably strong one. You outlined some other ones as well.

Part of curation is conversation - sharing with the community which packages people rely on for their projects, which have been tried and should be avoided, etc. That kind of information is hard to glean from github issues, and threads on ROS answers are hit and miss in this regard (has anyone ever asked, did someone who knows the answer see the thread, is a 5 year old answer still valid, etc.)

I think a software release announcement list would help with the curation problem. If software releases are being announced fairly regularly, that’s a positive indicator that the software is being looked after. Release announcement threads also give a venue for other users to make public comments on the releases, which lets us know that other people are using the package successfully. Tagging and enforcing some kind of experimental/developmental/stable spectrum and source/binary indication would go a long way towards satisfying your concerns of only being interested in high quality software.

For what it’s worth, that information could also be enforced through REP, by e.g. mandating the use of semantic versioning or adding stability and supported rosdistro metadata to package.xml files. I think that’s a separate conversation though.


#17

I think I agree with all of @Daniel_Stonier’s points. However, perhaps we should first get people to post here at all before taking measures to deal with an expected flood of posts. :slight_smile:

Also, having a binary release is only one sign that the package is high quality. This rule would exclude such projects as Google Cartographer, which are high quality, have a good test coverage + documentation, but no binary ROS release.

Anyway, I don’t care too much one way or another. We can still change the rule later if it doesn’t work.

https://google-cartographer-ros.readthedocs.io/en/latest/


#18

I think tagging is better than restricting to binary releases at this stage. I do not think that we will have such a huge quantity of announcements that it will be a flood control problem. When it gets to that point, the policy can be revisited.


#19

Part of the goal of moving to this forum has been to increase the communication within the community and I’m glad to say it has gone noteably up. As an aside there’s some rough stats here

But if you have suggestions about how to incentivise more posting and announcements that would be great. But I think that one of the biggest things is to just generate more content. Content draws people, people who are here post new things, which draws more people.

We also created the Projects category for the unreleased raw project discussions. Creation thread here.


#20

Just a point to the Off-Topic binary releases: After spending many hours trying to grasp all required aspects of releasing an existing ROS package as binary release, Matthias, a student of mine, has been working on http://wiki.ros.org/ROS/ReleasingAPackage
This is still WIP, but contributions, comments and “documentation testing” is highly welcome.


#21

I agree this thread indicates that releasing is easier once you know and could use some work to help that, but we should move that discussion to another thread.


#22

As an aside, rosindex.github.io could be modified to generate an RSS feed of new packages, even distro-specific ones, or ones that depends on certain packages. The only thing that’s lacking at the moment is funding to keep it generated frequently enough to be useful.


#23

Thanks for the links Tully, especially regarding the forum structure.

I’d still like to move forward on having a category dedicated to software release announcements as described above. I believe it is significant enough to have it listed up front for new users to find rather than be hidden internally somewhere as a tag. I also think it has enough differentiation from the Projects group to warrant its own category. I would for example have been interested in tuning into notifications about software releases but not projects over the last two years (would read them at my leisure) and I’d visit it frequently enough to find a repeated filter applied to viewing the projects category tiring.

It’s also a way of reducing the barrier in a small way to get people using each other’s software, which would in turn foster contributions and collaboration. Best motivation imo.


#24

I like the human in the loop for this - it’s a forum and the interaction with a human for a newly introduced package is valuable. It could be useful having rosindex do notifications of its own though (future feature request ;))


#25

I always thought that a little tagging of packages would go a long way. At one point I was trying to get people to tag their packages with CategoryURDF on the wiki to mark all urdf examples.


#26

@tfoote could we have a yea or nay on the creation of a Software Release Announcements category? Or whatever it takes to decide one way or another on the creation of a new category?


#27

Aye, I sometimes feel the community was noisier when it was 10 times smaller!


#28

@Daniel_Stonier How about we just explicitly add that to the description of General and ask people to announce there with a tag “release”. This is the same as previously announcing it to ros-users.

I’d rather not segregate it away until it becomes overwhelming to avoid fragmentation and decision paralysis for people posting.


Community Software Release Announcements - Guideline
#29

I guess I’m fine with that. It’s at least a place/convention we can encourage and not a topic that needs to be ‘walled off’ into an isolated forum. It hopefully will not have the ros-users problem too - there should be no discouragement from posting to it as discussed above.

My primary issue is in discovering/browsing for them. Tracking and discussing community software releases is such a core activity I would have liked all my devs engaging in. However, the current layout is very category-centric. The landing page displays a category based listing, the top banner does not have a tags drop down like at https://try.discourse.org/. Knowing the tag convention and then searching for a tag is not a process I think many of them would have done without laying it down for them. Shifting what should be one of the most common (or encouraged to be) activities on discourse to a tag based approach when the site is mostly category-centric is a little clunky.


#30

If everyone’s ok with this, I’ll move forward with an email to ros-users advocating posting in General with the release tag tomorrow. Please post if you have any different thoughts before then!

@tfoote can we get a Tags dropdown on the discourse landing page like at https://try.discourse.org/? If it’s the discourse-tagging plugin you’re using, instructions are here - Enable Tags menu/filter. If it’s part of the newer versions of discourse, probably the instructions are similar.


#31

I found the tag dropdown option and have turned it on. You should see it at the top of all listings now.