Our software should be production ready

[ct2034]

There is a feature in ros-industrial to indicate the development state (Production ready / Developmental / Experimental) of software on its wiki page (https://wiki.ros.org/Industrial/Software_Status)
I think we should include this in our wiki pages http://wiki.ros.org/pilz_robots. What do you think? @PilzDE/robotics

[dbakovic]

I like the idea

[hslusarek]

I'm support this suggestion. However, I'm not sure to what you refer here. Do you refer to a certain release-tag on our git repositories, to the most recent commit on the devel branches or to a certain release of one of our packages? @ct2034

[jschleicher]

Related: https://www.ros.org/reps/rep-2004.html

[martiniil]

Shall we apply this on package or repo-level?

I think we cannot rely on the stability of dependent packages. So the stability has to be ensured by our maintenance. Do we plan to maintain pilz_trajectory_generation (the "old" planner code) in the future?

pilz_robots:

• prbt_hardware_support is still unstable
• pilz_control: known bug Joint trajectory controller: Keep executing trajectory when aborted? ros-controls/ros_controllers#48 -> not production ready?

pilz_industrial_motion:

• pilz_store_positions = unstable? API is expected to change in the future.
• pilz_trajectory_generation: will it be maintained?

psen_scan: (old firmware)

Are there any objections to label it production ready?

[ct2034]

@martiniil
I think it is supposed to be defined on the package-level. It is a tag to be included in the wiki. See https://wiki.ros.org/industrial_core for an example. So, I don't think we should add it to the meta-packages but only to the packages themselves.

On your second question: Currently we are not planning to maintain planner code at the "old" location.

[gavanderhoorn]

You're of course free to use this as you see fit with your packages, but I just wanted to draw attention to the Status Hierarchy section (emphasis mine):

The software status indicators shall apply to ROS-Industrial releasable software units (meta-packages and/or repositories). In some cases, package level status may also be given when appropriate (although this is not desired).

I can imagine though that to avoid any ambiguity or to be as clear as possible (ie: discoverability) you'd assign status to individual packages.

[ct2034]

nvm