Finding the right place for your patch

OpenEmbedded is now split up into separate layers: OpenEmbedded-Core (OE-Core) which is a small set of core recipes, and other layers for recipes beyond that. For most layers, patches are sent to a mailing list for review before being merged. Further information specific to the layer you're working on please see the README file in the layer.

New recipes in particular should be added to the appropriate layer. See the layer index for the list of public layers. If your new recipe doesn't seem to fit anywhere it can be added to the meta-oe layer in the meta-openembedded repository, although if it is likely to be followed by numbers of similar recipes then you may wish to consider creating a new layer.

A task-oriented guide to creating a patch

Let's say you have made a fix to a recipe, you've tested that it works and you'd like to submit it for merging.

You can use the --envelope-sender option to have the email appear from the address you are subscribed to the list with. You will need to use the Accounts and import tab under the gmail settings tab. Use the Send mail as selection to address you want to send email from.

Subscribe to the mailing list

You need to subscribe to the appropriate mailing-list in order to be able to send your patch(es) there; for patches against OE-Core the mailing list is openembedded-core@lists.openembedded.org and for patches against meta-oe and many other layers the list is openembedded-devel@lists.openembedded.org. See Mailing lists for subscription and further details.

Committing your patch

Commit with a concise and descriptive message - one that explains your changes in a way others get a short overview without looking at the code.

Note that when adding multiple new recipes, each recipe should be added in a separate commit. For upgrades of existing recipes, the previous version should usually be deleted as part of the same commit to add the upgraded version.

Sending patches

There are two possible methods for submitting patches. Either one is acceptable; for a series containing a number of patches the pull request method is preferred although not mandatory.

Sending using git-send-email

To send just the top commit on your current branch (substitute mailing list address as appropriate):

For multiple commits you can substitute -1 above with -N (where N is the number of commits) or instead specify a revision before which to start e.g. HEAD~3, master etc.

Note: in either case if you are submitting a patch for meta-oe or any layer other than OE-Core, please add the appopriate prefix so that it is clear which layer the patch is intended to be applied to:

--subject-prefix="meta-oe][PATCH"

Please substitute "PATCH" with "PATCH v2" if you are submitting a revised version after addressing feedback (or v3, v4 etc.)

Sending via a pull request

Alternatively, for larger patch series it is preferable to send a pull request which not only includes the patch but also a pointer to a branch that can be pulled from. This involves making a local branch for your changes, pushing this branch to an accessible repository and then using the create-pull-request and send-pull-request scripts (supplied with OE-Core) to create and send a patch series with a link to the branch for review. Step-by-step instructions:

Find a repository to push your changes to, and add this as a remote to your git working tree. If you're going to be submitting a lot of changes, some of the repositories have a corresponding -contrib repository which you can use for this purpose - access to these for OE-related work is open to anyone who requests it. Otherwise github or some other public git hosting service can suffice.

Create a branch for your changes if you haven't already. Other than backports from master or fixing bugs that only occur in an older branch, this should be on top of the master branch.

Push the branch to the remote.

Run scripts/create-pull-request -u remote-name (where remote-name is the name of the remote where you'll be pushing the branch). For meta-oe and other layers where a single mailing list covers more than one layer you'll need to add -p "layername][PATCH" replacing layername with the name of the layer so that it is clear which layer the patches are intended for.

The script will report that it has created a pull-XXXXX directory has been created. Edit the pull-XXXXX/0000-cover-letter.patch with your favourite text editor and change the title and top of the body as appropriate.

Run scripts/send-pull-request -p pull-XXXXX -t openembedded-core@lists.openembedded.org (replacing openembedded-core@lists.openembedded.org with the appropriate mailing list address for layers other than OE-Core). Where there is a clear maintainer for the area you're changing it may also help to add -C maintainer@example.com.

Community review

If you get feedback in reply to your patch, you should make changes according to the feedback and submit the next version. Please remember to use --subject-prefix="PATCH v2", v3, v4 etc. to mark the patch iteration.

If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback.

Appendix

Steps for people which don't have SMTP access for git

Patches should not be sent as attachment but inline.

If you do not have SMTP access to your email account you have two options:

1. Use a different account (e.g. gmail). you can make one especially for this. Note that the account may differ from the one in signed-off (although that is inconvenient)

2. Just include the patch in the body of your email. Make sure you use an email client that does not touch the message (turn spaces in tabs,
wrap lines etc etc).