|
|
| (4 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| 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.
| | This page has moved to the [https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html Yocto Documentation Contributors Guide] |
| | |
| 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 ==
| |
| | |
| # Keep all of your own changes in the poky-contrib tree before requesting for acceptance
| |
| # When you're ready for submission, compose a merge message by running this script:
| |
| #* scripts/create_pull_request.
| |
| # Compose a merge mail based on above body information, plus:
| |
| #* add a [PULL] prefix in the mail subject
| |
| # Send the merge mail to the poky mailing list as possible, with notes:
| |
| #* No confidential information there.
| |
| # 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
| |
| # Revise your branch based on comments and jump back to step 2 for another merge request
| |
| # Richard/Saul pulls target branch into Poky upstream
| |
| | |
| == Access to git.yoctoproject.org Repositories==
| |
| | |
| There are a number of git repositories at the [http://git.yoctoproject.org/cgit/cgit.cgi/ 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 Access ===
| |
| | |
| To access a repo from git.yoctoproject.org, including poky-contrib, please send an email to [mailto:mhalstead@linuxfoundation.org Michael Halstead] with an ssh key from each person needing access along with the list of repositories you're trying to contribute to.
| |
| | |
| == Poky Contrib Repository ==
| |
| | |
| Once you have access, you will be able to clone and push to:
| |
| | |
| <pre>git@git.yoctoproject.org:poky-contrib.git</pre>
| |
| | |
| 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:
| |
| | |
| http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/
| |
| | |
| Where existing user branches can be seen.
| |
| | |
| == Git workflow ==
| |
| | |
| [http://git.yoctoproject.org/cgit/cgit.cgi/poky/ Poky] is a read-only repository that only the maintainers are able to write to. For contributions, there exists [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/ poky-contrib]. The first part of the git workflow explanation intends to let you know how to use these two repositories for:
| |
| | |
| # Base your code changes from the poky repository
| |
| # Publish your contributions to the poky-contrib repository
| |
| | |
| You can skip to the [[Poky_Contributions#Clone_a_Repository_from_git.yoctoproject.org | 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):
| |
| | |
| <pre>$ git clone git://git.yoctoproject.org/poky</pre>
| |
| | |
| === 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:
| |
| | |
| '''Read-only:'''
| |
| | |
| <pre>$ git remote add poky-contrib git://git.yoctoproject.org/poky-contrib</pre>
| |
| | |
| '''Read-write:'''
| |
|
| |
| <pre>$ git remote add poky-contrib ssh://git@git.yoctoproject.org/poky-contrib</pre>
| |
| | |
| === 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 [http://git.yoctoproject.org/cgit/cgit.cgi/ git.yoctoproject.org] that is not Poky, you can just clone it either read-only or read-write as follows:
| |
| | |
| '''Read-only:'''
| |
| | |
| <pre>$ git clone git://git.yoctoproject.org/<repository-name></pre>
| |
| | |
| '''Read-write:'''
| |
|
| |
| <pre>$ git clone ssh://git@git.yoctoproject.org/<repository-name></pre>
| |
| | |
| | |
| === Developer Git Branches ===
| |
| | |
| Create a branch, originating at the tip, that you will push:
| |
| | |
| <pre>git checkout -b name/topic-of-branch</pre>
| |
| | |
| 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'''
| |
| <pre>git push -u poky-contrib branch-name:remote-branch-name</pre>
| |
| | |
| '''Pushing to any other repository:'''
| |
| | |
| <pre>git push branch-name:remote-branch-name</pre>
| |
| | |
| When this is done, you'll be able to see your branch at the [http://git.yoctoproject.org/cgit/cgit.cgi/ 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:
| |
| | |
| <pre>
| |
| 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>
| |
| </pre>
| |
| ----
| |
| <pre>
| |
| gypsy: Fix broken SRC_URI
| |
| | |
| Signed-off-by: Scott Garman <scott.a.garman@intel.com>
| |
| </pre>
| |
| | |
| ''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.
| |
