BugReporting

== How to report a syskit bug

As with all bug reports, a good syskit bug report is essential to get your problem fixed. A bad one will, worst case, make the bug report ignored by the developers (because they don't have time to decipher / ask the questions necessary to make it a good report) or make them reply with a link to this page.

A good report is to the point. It clearly states what the problem is in terms of (1) what you are running, (2) what is the result you get and (3) what is the result you expect. Ideally, it also offers a way to reproduce. It can be tricky with syskit, we'll get to that in a second step.

Here's an in-depth essay on the topic. I suggest you have a look at it, it is quite the eye-opener.

Giving a way to reproduce a Syskit bug

There are basically two ways to do that:

1. create a fresh bundle, make it fail the way you think your application fails. That is the easiest as it reduces the context to a minimum, making debugging that much easier. Once you've created the new bundle, create a zipfile or tarball of this new bundle and put it somewhere it can be downloaded from (unfortunately, github has no way to attach files to the issues).

2. give me a copy of all your bundles and all your orogen models. So far, this basically entails giving a copy of all your orogen files, model files, and type definitions. Difficult if it is confidential. There could be ways to reduce the amount of information "leaked", but so far I had no incentive to develop a tool for it. You do this by creating a zipfile or tarball of your bundles/ folder as well as creating a model pack by running

rock-pack-models issue131

This creates an issue131.tar.bz2 tarball. Give access to both this file and the packed bundles/ folder. Github has no way to attach files to an issue, so it has to be external.