|
|
| (6 intermediate revisions by 2 users 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
| |
| | |
| == Poky Contrib Branch ==
| |
| | |
| To access the poky-contrib tree please send Michael Halstead an ssh key from each person needing access. You will then be able to clone and push to:
| |
| | |
| git@git.yoctoproject.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.yoctoproject.org/cgit/cgit.cgi/poky-contrib/
| |
| | |
| Where existing user branches can be seen.
| |
| | |
| == Git workflow ==
| |
| | |
| Clone the main git tree (if you haven't already):
| |
| | |
| git clone git://git.yoctoproject.org/poky
| |
| | |
| Add the poky-contrib as a read only remote repository:
| |
| | |
| git remote add poky-contrib git://git.yoctoproject.org/poky-contrib
| |
| | |
| - or since you probably want to be able to push your branch back to poky-contrib, check it out as a read/write repository:
| |
|
| |
| git remote add poky-contrib ssh://git@git.yoctoproject.org/poky-contrib
| |
| | |
| Create a branch, originating at the tip, that you will push to poky-contrib:
| |
| | |
| 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. When they are ready, you can push them:
| |
| | |
| git push -u poky-contrib 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.
| |
| | |
| When this is done, you'll be able to see your branch at http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/
| |
| | |
| Once it's merged please remember to delete your branch from poky-contrib.
| |
| | |
| == 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.
| |
