Contributing

We welcome PRs that improve tooling, documentation, or hardware support—but every change must respect our pillars: safety, performance, developer experience, and zero debt. Follow this checklist to keep the review loop quick.

Development Workflow

  1. Branch from master — keep your changes focused and rebase before submitting.
  2. Format Zig sources — mise run fmt (mirrors CI).
  3. Run host tests — zig build test -Doptimize=Debug and -Doptimize=ReleaseFast (or simply mise run test-tiger). Add new tests under tests/ and import them through tests/all.zig so the src/ tree stays free of inline tests.
  4. Cross build affected boards — e.g. zig build -Dboard=stm32f103-bluepill ....
  5. Simulate each board — mise run sim-<board> and inspect build/renode/<board>-uart.log. No warnings is the standard.
  6. Update docs — extend the mdBook when you touch behaviour or add hardware. “Done” includes documentation.
  7. Leave nothing half-finished — remove TODOs, resolve edge cases, and ensure defaults are explicit.
  8. Follow commit guidelines — use type(scope): description (e.g., feat(drivers): add spi backend).

Pull Request Expectations

  • Include a summary of changes and the commands you executed.
  • Mention any gaps (e.g., missing Renode support for a new peripheral) so reviewers can help plan follow-up work.
  • Keep the mdBook and README in sync with new features.

Reporting Issues

When filing a bug, include:

  • Zig version (zig version)
  • Renode version (renode --version)
  • Board(s) affected
  • Reproduction steps (commands + logs)

Screenshots of UART output or Renode monitors are encouraged when the behaviour is visual.

Roadmap

The high-level roadmap lives in SPEC.md. Feel free to propose additions via issues or discussions—especially for new board support or driver categories.