Link Search Menu Expand Document

Software Anomaly Reporting

Table of contents

  1. Overview
  2. Reporting Channels
  3. Tracking and Triage
  4. Fix Lifecycle
  5. Delivery and Communication of Fixes
  6. Related Pages

Overview

This page summarizes how ModalAI receives, tracks, and resolves software anomalies and trouble reports against the VOXL SDK, and how fixes are verified and delivered to users.

Reporting Channels

Software anomalies reach ModalAI engineering through three channels:

  1. GitLab issues — every VOXL SDK package is open source at https://gitlab.com/voxl-public, and each repository accepts issues. This is the preferred channel for developers, since a report lands directly against the affected component with its version and reproduction details.
  2. The ModalAI forum — https://forum.modalai.com is actively monitored by ModalAI engineers. Reports that turn out to be software defects are pulled into internal tracking.
  3. Direct support — customers and programs report issues through their ModalAI point of contact, who files the report internally on their behalf.

Tracking and Triage

Reports from all channels are triaged by ModalAI engineering. Confirmed or actionable anomalies are entered into ModalAI’s internal issue tracking system (Asana) and tracked there to resolution; externally filed GitLab issues are mirrored into the same internal tracking so all defects are worked from one queue. Supporting engineering analysis and design documentation is maintained in Confluence.

Anomalies are prioritized by operational impact:

  • Critical — defects affecting flight safety or system stability (crashes, loss of control or telemetry, fault-handling failures) are worked first and fast-tracked into the next patch release.
  • Functional — defects degrading a feature without a safety or stability impact are scheduled into the normal release cycle.
  • Minor — cosmetic or documentation-level defects are batched into future releases.

Fix Lifecycle

A confirmed anomaly follows the same configuration-controlled path as all SDK changes (see Configuration Management):

  1. The defect is reproduced and root-caused by engineering.
  2. A fix is developed and lands via a GitLab merge request, incrementing the affected package’s version.
  3. Automated CI builds the fixed package in the controlled build environment and publishes it to the development repository.
  4. The fix soaks through nightly SDK builds assembled from the development repository, where it is exercised on hardware — including bench and flight testing — alongside the rest of the SDK.
  5. The fixed package version is pinned into the next stable release, which passes the full release regression and flight-test gate before publication.

Delivery and Communication of Fixes

Fixes reach users through stable SDK releases:

  • Patch releases (e.g. 1.6.2 to 1.6.3) deliver fixes in place via apt update && apt upgrade against the stable sdk-x.y repository.
  • Minor releases deliver fixes alongside system image updates via a full system flash.

Every fix shipped in a release is documented in the release notes, which enumerate each package’s version change with a changelog, so users can determine exactly which defects a given SDK release resolves. Critical defects are prioritized for expedited patch release and highlighted in the release notes of the release that carries the fix.

When reporting an anomaly, include the SDK version (voxl-version), the affected package and its version (dpkg -l | grep <package>), and reproduction steps. This lets engineering trace the report directly to the exact software configuration involved.