Development Process

Every page of the Slint documentation has a Markdown version, ~10x smaller. Replace a link's trailing slash with .md: this page is /master/docs/safety/qualification-plan/development-process.md. /master/docs/safety/llms.txt lists all pages.

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.

TODO

Decide the toolchain policy for qualification evidence runs, such as a qualified Ferrocene release, and enforce it in scripts/slint_sc_test_suite.sh. Day-to-day development builds with stable Rust today.

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: Planned work and bugs are tracked via GitHub Issues, labeled a:slint-sc (https://github.com/slint-ui/slint/issues ↗).
• Authorization: A change merges once a reviewer approves it, unless the change is trivial, in which case review can be skipped. Trusted members, including admins, can also push directly to master without a PR or review, for simple changes. These commits are still recorded in the repository history and are still covered by the full CI suite, run regularly independent of any single push.
• Traceability: Every change lands in master as a commit, identified by its commit hash and retained permanently in history. Most commits are additionally linked to the pull request that introduced them, through GitHub’s PR/commit linkage; some carry a Fixes #NNN reference to the issue they resolve in the commit message. There is no requirement for a change to be linked to a ticket.

TODO

No impact analysis is currently performed for changes (ISO 26262-8, 8.4.3.1 requires one per change request). Decide what form this should take and how it fits into the PR flow.

Authorization currently rests with a single reviewer (or, for trivial changes, no one). ISO 26262-8, 8.4.4.1 envisions decision by project manager, safety manager, QA, and developers. Decide whether this needs a dedicated approval step for Slint SC, distinct from ordinary code review.

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 by SixtyFPS GmbH. That employees work remotely in different countries doesn’t create distributed development in the sense of this clause; they’re one organization under one process.

Development happens in the open, on the public slint-ui/slint ↗ repository, which hosts both the general-purpose Slint product and the code Slint SC is built from (the same compiler, a separate runtime library). Slint SC releases are cut from a dedicated branch, so only reviewed and released commits become part of a certified version.

The repository accepts pull requests from anyone, under an inbound MIT-0 license, including from contributors outside SixtyFPS. Clause 5.2, Note 2 excludes from its scope “procurement which does not place any responsibility for safety on the supplier.” SixtyFPS reviews, verifies, and tests every change before it is integrated, and retains full responsibility for all safety lifecycle activities, requirements, design, verification, and the safety case, regardless of who authored a given change. No safety responsibility is delegated to external contributors, so accepting community PRs does not by itself constitute distributed development under this clause.

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.