Poky Contributions

From Yocto Project
Jump to: navigation, search

We need a system for accepting changes to Poky and other Yocto Linux components. We already have a system established in the community for this and this will work for our distribution work too.

Poky has no built in submission process or policy. I see this as an advantage as we can be flexible and can adapt the process and policies to fit our needs. Our users are also free to adapt it to their situations which are likely to have different needs too. It does mean we need to clearly document how we work though.

Our submission process is for people to push to branches on the poky-contrib tree and then send a merge request in the same way the kernel submission process works (with the difference of a shared git tree). You will have seen people on the Poky mailing list do this for community submissions.


Patch Submission Process

  1. Keep all of your own changes in the poky-contrib tree before requesting for acceptance
  2. When you're ready for submission, compose a merge message by running this script:
    • scripts/create_pull_request.
  3. Compose a merge mail based on above body information, plus:
    • add a [PULL] prefix in the mail subject
  4. Send the merge mail to the poky mailing list as possible, with notes:
    • No confidential information there.
  5. Once seeing the merge mail, either Richard or Saul will check candidate patches in target poky-contrib branch. If there are some improvements or further discussion required, Richard/Saul will reply with explanation in mail. Quotes should be provided instead of simply providing comments.
    • If all patches in the branch are in good form, jump to step 7
  6. Revise your branch based on comments and jump back to step 2 for another merge request
  7. Richard/Saul pulls target branch into Poky upstream

Access to git.yoctoproject.org Repositories

There are a number of git repositories at the Yocto Project git server. If you need to contribute to any of these repos you can follow the instructions below. Consider that poky-contrib is the most solicited repo so it is also the example that appears in the guide.

Request Write Access

To write to a repo on git.yoctoproject.org, including poky-contrib, please send an email to Michael Halstead and:

  1. Attach your ssh public key which usually named id_rsa.pub. If you don't have one generate it by running ssh-keygen -t rsa -b 4096 -C "your_email@example.com".
  2. List the repositories you're planning to contribute to.
  3. Include your preferred branch prefix for *-contrib repositories. See git.yoctoproject.org to see which prefixes are already in use.

Poky Contrib Repository

Once you have access, you will be able to clone and push to:


Or any of the other repositories at git.yoctoproject.org.

You might want to use git remote to pull from the master poky tree so that you pull in updates from there.

The tree is viewable at:


Where existing user branches can be seen.

Git workflow

Poky is a read-only repository that only the maintainers are able to write to. For contributions, there exists poky-contrib. The first part of the git workflow explanation intends to let you know how to use these two repositories for:

  1. Base your code changes from the poky repository
  2. Publish your contributions to the poky-contrib repository

You can skip to the Clone a Repository from git.yoctoproject.org section if you are not working in the poky-contrib repository, not all the repositories require this double relationship for contributions.

Git Clone Poky

Clone the main git tree (if you haven't already):

$ git clone git://git.yoctoproject.org/poky

Add poky-contrib as a Git Remote

You have the option to add the poky-contrib remote as a read-only (perhaps for the case where you haven't sent the ssh access keys) or as read-write if you have cleared your write access as indicated in Poky_Contributions#Request_Access. Execute only one of the two following instructions:


$ git remote add poky-contrib git://git.yoctoproject.org/poky-contrib


$ git remote add poky-contrib ssh://git@push.yoctoproject.org/poky-contrib

Clone a (non-Poky) Repository from git.yoctoproject.org

The process is simple for contributions that are not based off of the Poky repository. For any other repository at git.yoctoproject.org that is not Poky, you can just clone it either read-only or read-write as follows:


$ git clone git://git.yoctoproject.org/<repository-name>


$ git clone ssh://git@push.yoctoproject.org/<repository-name>

Developer Git Branches

Create a branch, originating at the tip, that you will push:

git checkout -b name/topic-of-branch

The convention is that the branch name contains your name followed by a forward slash and then the topic of the branch e.g. "michaelw/fixes-thing".

Add changes to this branch ensuring commit messages follow the standard format defined below.

Pushing Developer Git Branches

When your changes are ready, you can push them:

Pushing to poky-contrib

git push -u poky-contrib branch-name:remote-branch-name

Pushing to any other repository:

git push branch-name:remote-branch-name

When this is done, you'll be able to see your branch at the gitweb interface, just navigate to the repository you pushed it to.

Once it's no longer useful please remember to delete your branch from the remote.

Git commit messages

Commit messages should follow the standard format of having a single-line subject denoting the affected area of the code and summarising the change followed by a blank line then a more detailed description of the commit (not always necessary but more usually is) followed by the sign off line (added by passing -s to the commit command).

Some example commit messages follow:

icu-native: LD_LIBRARY_PATH is required

Back to commit ea45876d7ba3d4d2b132fd38a2c40834a2385f34, LD_LIBRARY_PATH
is disable for cross-build, however it's required for native version. So
force noldlibpath.patch for non-native case only

Signed-off-by Kevin Tian <kevin.tian@intel.com>

gypsy: Fix broken SRC_URI

Signed-off-by: Scott Garman <scott.a.garman@intel.com>

Note: the commit doesn't include a detailed message - this is suitable because the change is trivial and the subject line contains all of the required information.

Personal tools