Open gavanderhoorn opened 3 years ago
That does not sound like a LIVENESS
failure, at all.
If not sure if there is a right label for it, but I would guess that the SOFTWARE
is perfectly capable of making progress, despite the fault.
Yeah, I'm getting a bit confused about our definition of liveness. The following bugs all have LIVENESS
:
I've spot-checked these, and some don't describe runtime issues.
Could it be we've inflated liveness to include everything which could lead to loss of functionality?
Tentative conclusion: see whether SOFTWARE:NETWORK
should be reintroduced.
@ChrisTimperley @wasowski
All these bugs listed above seem to have SYSTEM:LIVENESS
in the excel sheet. These are not SOFTWARE:LIVENESS
turtlebot/3ea2c30 is about an env hook (basically a Bash script 'plugin') trying to find a directory which doesn't always exist (as it's a directory from a different package, which isn't listed as a dependency of the package in which the failing env hook is located):
https://github.com/robust-rosin/robust/blob/7e3932c4906a2851d1f84bfd96ecaa58924c9f57/turtlebot/3ea2c30/3ea2c30.bug#L4-L14
This is classified as
SOFTWARE:LIVENESS
.However, the net effects of that env hook failing are essentially:
source
s theirsetup.bash
(ie: activates a workspace)TURTLEBOT_MAP_FILE
environment variable not getting setbut the base functionality of the package itself (ie:
turtlebot_bringup
) is not affected. The robot can still be controlled, no software will fail to work, except some other package which might use this variable (some.launch
files inturtlebot_navigation
).Do we feel this is sufficient for a
LIVENESS
label?Edit: and the env hook also only sets a "sane default".