Poky Contributions

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 and this is also what Joshua Lock does when submitting changes.

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 Joshua will check candidate patches in target poky-contrib branch. If there're some improvements or further discussion required, Richard/Joshua 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/Joshua pulls target branch into Poky upstream

Poky Contrib Branch

To access the poky-contrib tree please send Richard Purdie an ssh key from each person needing access. You will then be able to clone and push to:

gitserver@git.pokylinux.org:poky-contrib.git

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:

http://git.pokylinux.org/cgit.cgi/poky-contrib/

where existing user branches can be seen. Since none of the work is confidential at this time, its fine to use the public server.

Git workflow

Note: this is approximately what I did, but not exactly, since I would do it differently now. Please fix these instruction if you try them and they don't behave as I say they should.

Clone the main git tree:

git clone git://git.pokylinux.org/poky.git

Create a branch, originating at the tip, that you will push to poky-contrib:

git checkout -b branch-name master

branch-name should probably contain your name somehow.

Add changes to this branch ensuring commit messages follow the standard format defined below. When they are ready, you can push them:

git push ssh://gitserver@git.pokylinux.org/poky-contrib.git branch-name:remote-branch-name

If you want to replace an existing branch on poky-contrib with a new one, i.e. you fixed something or the old one was merged and you want to reuse the branch for new patches, add -f to the git push command:

git push -f ssh://gitserver@git.pokylinux.org/poky-contrib.git branch-name:remote-branch-name

When this is done, you'll be able to see your branch at http://git.pokylinux.org/cgit.cgi/poky-contrib

Notes:

• You can probably use git remote to pull poky-contrib.git into your git repo, create a branch within that, cherry-pick patches from your master branch to your contrib branch, and have git know what the remote repository is, saving you from having to specify it in the push command.
• I think, but haven't tested, that if you just use branch-name as the last argument, it will use the same branch name on the remote side.

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.