QEMU Community Processes

Notes about how to interact with the community and how and where to submit patches.

• Code of Conduct
  • Sources
• Conflict Resolution Policy
  • How we resolve conflicts
  • Remedies
  • Sources
• The Role of Maintainers
  • The MAINTAINERS file
  • Becoming a reviewer
  • Becoming a maintainer
• QEMU Coding Style
  • Formatting and style
  • Language usage
  • QEMU Specific Idioms
• Submitting a Patch
  • Writing your Patches
  • Submitting your Patches
  • Retrieve an existing series
  • Participating in Code Review
  • Tips and Tricks
• Code provenance
  • Certifying patch submissions
  • Multiple authorship
  • Other commit tags
  • Subsystem maintainer requirements
  • Tools for adding Signed-off-by
  • Re-starting abandoned work
  • Inclusion of generated files
  • Use of AI-generated content
• Trivial Patches
  • Overview
  • Repositories
  • Workflow
  • Team
• QEMU and the stable process
  • QEMU stable releases
  • What should go into a stable release?
  • How to get a patch into QEMU stable
  • Stable release process
• Submitting a Pull Request
• Secure Coding Practices
  • Reporting Security Bugs
  • General Secure C Coding Practices
  • Input Validation
  • Unexpected Device Accesses
  • Live Migration
  • Guest Memory Access Races
  • Use of null-co block drivers
• Rust in QEMU
  • Building the Rust in QEMU code
  • Writing Rust code in QEMU
  • Adding dependencies