[ros-users] Software Status Reporting and Custom Builds

Edwards, Shaun M. sedwards at swri.org
Sun Sep 1 17:14:02 UTC 2013


Tully,

See my repsonses below


The Software Status's on the ros industrial page I think are an improvement over the REP 9 approach since the stability of a package is not necessarily monotonic nor necessarily are expectations the same in different contexts. (For example think of a stable package where development has picked up again for new features)   Along those lines I think that for these classifications to be useful they actually have to have specific meaning. "production" in one context may be very different in another context.  Likewise I think it might be better to think about stating specific dimentions, such as "this API will have a 2 year stability cycle going forward" vs "this API will be stable for the next week".  These classifications should communicate the intentions of the developer/maintainers to the users more than the metrics.

I hadn't thought of it this way.  I can see where this information would be useful for migrating from ROS version to the next.  In ROS-I we don't make any guarantees about API stability between ROS releases, but we do make guarantees within ROS releases for "production" code.  We had several users who were using packages that we were still developing.  As you can imagine they weren't happy when we made changes that broke their code or when they found a significant number of bugs.  The software status is a simple way of conveying the developers intent.

Providing a mechanism for providing metrics on packages is definitely feasible.  Johannes Kuehn has done some great work putting together a complete working prototype during his internship at Bosch. He's been able to put together analysis which runs on the buildfarm, uploads data and renders it into the wiki.  It still needs some cleanup to be generally deployed but you can see an example of the wiki macro he put together to demonstrate the results at: http://wiki.ros.org/actionlib  The longer term vision of this project is to have this analysis running just like our continuous integration jobs with the results rendered into the standard PackageHeader macro.  Most of what's left is to polish up the proof of concept and make it stable enough to be deployed on the buildfarm unsupervised.  Most of the code is on github at: https://github.com/ros-infrastructure/jenkins_scripts/tree/master/code_quality and the wiki macro is in the roswiki repo: https://github.com/ros-infrastructure/roswiki

This is very nice.  I'm not an expert on metrics, but the descriptions are pretty clear and I can see value in the charts.  Is there a plan for wider deployment of this solution?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130901/f0fad23c/attachment.html>


More information about the ros-users mailing list