May Quality Assurance Working Group Meeting

Quality Assurance
1

All,

The next ROS Quality Assurance Working Group will take place 2020-05-07T14:00:00Z.

The meeting agenda is below. Please comment with any other agenda items you would like to add. We presently do not have a talk scheduled but I am more than open to community suggestions. In the absence of a talk I would like to discuss our upcoming RSS workshop. I am planning to create a “turn-key” empty ROS project template that includes most of the CI tools considered “best practices”. I would like to discuss with the community what should be included in that template.

The agenda for this meeting is quite short this time so please do make suggestions of topics we should discuss.

Agenda:

Conference Call Details:

  • Date and Time: 2020-05-07T14:00:00Z.
  • Meeting ID meet.google.com/woa-jzyw-rjx
  • Phone Numbers ‪US‬‪+1 413-752-0046‬ / PIN: ‪622 664 351#‬
2 Likes
2

That’s at 2020-05-07T14:00:00Z for all us non-PST people.

1 Like
3

Bumping this as a reminder.

4

It’s a great idea to create a official quality template. We also did this in our department and it was the biggest step for us in terms of quality. Our template was based on this repo:

3 Likes
5

This is great. Thanks a bunch.

6

Here’s my summary for the meeting.

Lots of feedback on RSS workshop / new package paster template. Here are is a list of things to potentially include.

  • Coverage
  • Clang Lint
  • Static analyzer
  • ABI credibility check
  • AWS tooling in general.
  • Industrial CIi
  • Default set of github actions for ROS
  • Any/ All ROS Tooling
  • Basic container usage patterns
  • code-coverage
  • clang-tidy
  • cppcheck
  • sanitizer
  • include-what-you-use
  • benchmark (google)
  • How to architect code such that the “heavy lifting” is done as a stand-alone library.

Other topics:

Next Meetings:

  • June 4th, 2020. Speaker TBD. I’ll post new invite two weeks out.
  • July - Kat will present RSS workshop.
7

This look really really good :slight_smile:

It would be great to have a script which creates a package and also add every one could have. The script could do this based on some *.yml file or interactively.

Is there anywhere the full list of stuff one can/should add to a package?

8

I wouldn’t call that the final list, it is more like a set of candidate features. I am not sure it would be a script so much as an empty project stub with a check list and a lot of documentation about how to configure it. There isn’t always good overlap between the people who can do “ops” well, and those who can write software well. The hope here would be to bridge that gap and define “best practices” in an easy to use way.