Development Phases

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-phases.md. /master/docs/safety/llms.txt lists all pages.

Slint SC is developed in the same repository as Slint, slint-ui/slint ↗, and follows the same process as the rest of the repository ↗. There is currently no Slint SC-specific tightening of this process.

Branching

Organization members create branches usually named <developer-name>/<feature-name> in slint-ui/slint. Outside contributors work from a fork and open a PR from there, since only organization members can push to slint-ui/slint.

master and feature/* branches are protected. Trusted members, which implicitly includes admins, can push directly to these branches. For simple changes that don’t need review and are unlikely to break CI, a push can push straight to master without a PR.

Pull Requests and Review

A PR should be reviewed before merging, unless the change is trivial. Reviewers leave comments; some are nitpicks, others must be addressed before merging, and reviewers indicate which is which. There is no independent-reviewer requirement beyond ordinary review, and no distinction between safety-impacting and other changes at review time.

Once a PR is approved, the author merges it; auto-merge can be used once CI passes and approval is in. For external contributions, the reviewer merges instead.

Merges to master are squash or rebase only; GitHub is not configured to allow merge commits, so history stays linear. A feature branch can be merged into master with a merge commit, but only by an admin.

Continuous Integration

CI runs on every PR and a full CI runs three times a day on the latest master branch. PRs that touch files relevant to Slint SC additionally run scripts/slint_sc_test_suite.sh, which exercises the Slint SC test suite and measures the runtime’s coverage; this is part of, not separate from, the full CI suite, which also runs on a fixed schedule three times a day independent of any single change. What counts as “relevant” is currently determined by file path, though this is an imprecise proxy since the compiler is shared between Slint and Slint SC.

Traceability

Every merged change is a commit in master’s history, identified by its hash, and stays there permanently. Most commits are linked to their originating PR through GitHub’s own linkage; some additionally reference the issue they resolve via Fixes #NNN in the commit message. Not every change is tied to a ticket: a PR number or commit hash is treated as sufficient for tracking on its own.

TODO

A release is planned to be cut from a dedicated branch, but the branching and freeze process for a release is not yet decided.