[ros-users] Software Status Reporting and Custom Builds

[Tully Foote]

On Sat, Aug 31, 2013 at 4:01 AM, Austin Hendrix <legotown at aol.com> wrote:

>  On 08/31/2013 03:39 AM, Edwards, Shaun M. wrote:
>
>  All,****
>
> ** **
>
> We have received feedback from the users of ROS-Industrial on two issues
> that I think are important to the larger community.  We have taken
> preliminary steps to address these issues, but in no way would we consider
> these the correct or permanent solutions.  It is for this reason, I am
> address the ROS user’s group to solicit feedback and discussion about these
> two issues:
>
>
Thanks for starting the discussion I we can get the whole community
involved with this.

> ****
>
> ** **
>
> 1.       Stack/Meta-Package/Package Status – Many people have commented
> that it is hard to know the true status of a package (whether the code is
> complete or in development).  The existence of a wiki is not an indicator,
> as several packages in ROS (including some of our own) are released early
> (i.e. agile development).  For this reason we have started identifying the
> status of a package on our wiki pages (see:
> http://ros.org/wiki/Industrial/Software_Status ).  Here is an example of
> a stack/meta-package that has been marked with its current status:
> http://ros.org/wiki/industrial_core .  This is only a start to what I
> think needs to be done, but it solves and urgent need for us and all the
> developers that are using our software.  I would like to see this status or
> something similar used by the larger community (what to you guys think).
>
>
> +1. For the PR2, I primarily rely on the old 1.0/pre 1.0 version status,
> where stacks with version 1.0 and greater are defined as "stable" and
> pre-1.0 stacks are defined as unstable. This is mentioned in REP-9 (
> http://ros.org/reps/rep-0009.html ), but isn't always well-followed
> outside of the PR2 ecosystem.
>
>
>
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.


>  ****
>
> 2.       Code quality/testing/metrics – Several users have asked for this
> type of information about our packages.  This is one of the (not the only)
> reasons we set up a Jenkins server specifically for ROS-Industrial (see
> http://rosindustrial.org/news/2013/8/13/jenkins-system-for-ros-industrial-repositories).  The ROS community already utilizes Jenkins servers for continuous
> integration and debain builds, but code metrics are missing (even some as
> simple as how many compiler warnings are generated).  We would like to see
> this kind of data rolled into official ROS Jenkins servers.  Is this a need
> for those in the large community?
>
> +1 for metrics and better integration with the build system. The build
> system already runs tests as part of the deb build process, but ignores the
> test results and continues the build regardless. The devel jobs also run
> the tests and email build results to the package authors.
>
> If we want to make this more visible, I would love to see a wiki macro
> that allows us to summarize the test results on the stack/package page,
> probably both the deb build test results and the devel test results. This
> probably means exporting the test result xml files from the build farm to a
> public server, and parsing them from the wiki.
>

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

Tully
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130831/3b116173/attachment.html>