Yocto Project and OpenEmbedded Contributor Guide

The Yocto Project and OpenEmbedded are open-source, community-based projects so contributions are very welcome, it is how the code evolves and everyone can effect change. Contributions take different forms, if you have a fix for an issue you’ve run into, a patch is the most appropriate way to contribute it. If you run into an issue but don’t have a solution, opening a defect in Bugzilla or asking questions on the mailing lists might be more appropriate. This guide intends to point you in the right direction to this.

Table of Contents

• 1 Identifying the component
• 2 Reporting a Defect Against the Yocto Project and OpenEmbedded
• 3 Recipe Style Guide
  • 3.1 Recipe Naming Conventions
  • 3.2 Version Policy
  • 3.3 Version Number Changes
  • 3.4 Recipe formatting
    • 3.4.1 Variable Formatting
    • 3.4.2 Python Function formatting
    • 3.4.3 Shell Function formatting
  • 3.5 Recipe metadata
    • 3.5.1 Required Variables
    • 3.5.2 Recipe Ordering
    • 3.5.3 Recipe License Fields
      • 3.5.3.1 License Updates
    • 3.5.4 Tips and Guidelines for Writing Recipes
  • 3.6 Patch Upstream Status
    • 3.6.1 Examples
  • 3.7 CVE patches
    • 3.7.1 CVE Examples
  • 3.8 Patch format
• 4 Contributing Changes to a Component
  • 4.1 Contributing through mailing lists — Why not using web-based workflows?
  • 4.2 Preparing Changes for Submission
    • 4.2.1 Set up Git
    • 4.2.2 Clone the Git repository for the component to modify
    • 4.2.3 Create a new branch
    • 4.2.4 Implement and commit changes
    • 4.2.5 Test your changes
  • 4.3 Creating Patches
  • 4.4 Validating Patches with Patchtest
  • 4.5 Sending the Patches via Email
    • 4.5.1 Using Git to Send Patches
    • 4.5.2 Setting up Git to Send Email
    • 4.5.3 Finding a Suitable Mailing List
    • 4.5.4 Subscribing to the Mailing List
    • 4.5.5 Sending Patches via Email
    • 4.5.6 Troubleshooting Email Issues
      • 4.5.6.1 Fixing your From identity
    • 4.5.7 Streamlining git send-email usage
  • 4.6 Using Scripts to Push a Change Upstream and Request a Pull
  • 4.7 Submitting Changes to Stable Release Branches
  • 4.8 Taking Patch Review into Account
  • 4.9 Tracking the Status of Patches
• 5 AI-Assisted Contribution Policy
  • 5.1 Scope
  • 5.2 General conditions
  • 5.3 Human responsibility
  • 5.4 Signed-off-by tags
  • 5.5 Patch upstreaming
  • 5.6 Transparency
    • 5.6.1 In patches and commits
    • 5.6.2 In emails, bug reports and security reports
  • 5.7 Fully automated contributions
  • 5.8 Privacy and confidentiality
  • 5.9 Enforcement

---

The Yocto Project ®

<docs@lists.yoctoproject.org>

Permission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-Share Alike 2.0 UK: England & Wales as published by Creative Commons.

To report any inaccuracies or problems with this (or any other Yocto Project) manual, or to send additions or changes, please send email/patches to the Yocto Project documentation mailing list at docs@lists.yoctoproject.org or log into the Libera Chat #yocto channel.