SYSTEM:NONE incorrectly assigned?

[git-afsantos]

I was looking for examples of SYSTEM:NONE that were neither SOFTWARE:BUILD nor SOFTWARE:NONE.
Some examples, such as kobuki/4115400 seem debatable, considering the new set of system labels that we have.

In this particular case:

When multiple Kobuki robots were spawned in the Gazebo simulator their translations would properly update their odometry, but rotations would not.
The underlying issue was that every robot instance was using the same IMU sensor, instead of each having its own.

Wouldn't this be SYSTEM:MONITORING now?

Failures that result in inaccurate observation and diagnosis of the system's current state, via user interfaces of various types.

I suspect other cases might be in a similar situation. We should use this issue as a reminder to double check SYSTEM:NONE bugs.

[hsd-dev]

I think this comes from our discussion long back that we consider simulation as SYSTEM:NONE. Did I misunderstand that?

[git-afsantos]

Oh, I might have missed that. If we are treating simulation separately, then it is ok.

[hsd-dev]

Are there more examples of this? Maybe the other bugs are not simulation-related, in which case the labels need to be fixed.

[git-afsantos]

There are more bugs fitting my original parameters:

• SYSTEM = NONE
• SOFTWARE != {NONE, BUILD}

I haven't gone through all of them, and some might require knowledge about the system that I don't have.
For instance, a mavros bug used incorrect namespaces for parameters. It is marked as SOFTWARE:UX, and I do not know if it is truly SYSTEM:NONE or SYSTEM:MONITORING, because the parameters are related to visualization.

I just used the search bar here on GitHub with SYSTEM:NONE and went through bugs that had something different in SOFTWARE. Since the two labels are close together, you can see both in the search result previews.