--- title: "Development Process" description: "Tools, processes, and infrastructure used for Slint SC development." --- 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](/qualification-plan/standards-compliance/#iso-26262-clause-map) 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](/qualification-report/test-results/) chapter, by the run itself, so the number can't drift from reality. :::caution[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](/evaluation-report/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](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](/qualification-report/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](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. :::caution[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](https://github.com/slint-ui/slint/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](/evaluation-report/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](https://github.com/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](/user-manual/) states what each side is responsible for.