Development Process

This chapter describes the tools we use and the processes we follow to develop Slint SC. It addresses the supporting processes of ISO 26262-8, Clauses 5 to 16. Standards Compliance maps each clause to its section.

Language and Compiler

The slint-compiler translates .slint files into Rust code. Slint SC is itself written in Rust.

The toolchain that built and ran each evidence run is recorded in the Test Results chapter, by the run itself, so the number can’t drift from reality.

The confidence level these tools need, and how each one reaches it, is in Tool Classification.

Configuration Management

Addresses: ISO 26262-8 Clause 7

Slint SC utilizes a structured configuration management process to ensure artifacts are reproducible and traceable.

Version Control: Slint is hosted on GitHub (https://github.com/slint-ui/slint ↗).
Baselining: Each release is prepared on a release/Major.Minor branch and tagged vMajor.Minor.Patch. The tag is the baseline: the qualification evidence of a release is produced from it, and the Test Results chapter records the commit and the toolchain of the run.
Nightly Builds: Automated nightly builds generate documentation, examples, and release artifacts to provide continuous visibility into the master branch’s stability.

Change Management

Addresses: ISO 26262-8 Clause 8

Modifications to the Slint SC codebase are managed to preserve the safety and integrity of the system.

Reporting and Tracking: Issues, bugs, and feature requests are tracked via GitHub Issues (https://github.com/slint-ui/slint/issues ↗).
Impact Analysis: Before implementing a change for a safety-related concern, an impact analysis is conducted to ensure the modification will not compromise existing safety mechanisms or introduce new hazards.
Authorization: A change is authorized by review. The merge requirements, including who counts as an independent reviewer, are stated once, in Development Phases; the review is the opportunity to challenge the impact analysis before merging.
Traceability: Every change is traceable to its reviewed PR. A major change is additionally traceable to its approved ticket, which records the motivation, the proposed solution, and the impact analysis.

CI System and Infrastructure

Continuous Integration (CI) is achieved through GitHub Actions ↗. Workflows run for any Pull Request (PR) and for any push to the master branch, and a failure blocks merging the PR.

The CI system doesn’t generate code that ships, but a run that reports green without having run the tests would hide exactly the errors the tests exist to catch, which is the fail-to-detect case of tool classification. Its classification belongs with the rest of the test tooling in Tool Classification.

Distributed Development

Addresses: ISO 26262-8 Clause 5

Clause 5 governs development distributed across organizations: the interfaces between a supplier and its customers. Slint SC is developed within SixtyFPS GmbH alone, so there is no distributed development on our side. That employees work remotely in different countries doesn’t change this; they’re one organization under one process.

The interface the clause does reach is the one to the integrator. Slint SC is an SEooC, and the User Manual states what each side is responsible for.