Poky Contributions: Difference between revisions
Michael Wood (talk | contribs) (Advise using git remote add for poky-contrib repo, remove a few of the inline commentary) |
Michael Wood (talk | contribs) mNo edit summary |
||
Line 31: | Line 31: | ||
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/ | http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/ | ||
Where existing user branches can be seen. | |||
== Git workflow == | == Git workflow == | ||
Clone the main git tree: | Clone the main git tree (if you haven't already): | ||
git clone git://git.yoctoproject.org/poky | git clone git://git.yoctoproject.org/poky | ||
Add the poky-contrib as a remote repository: | |||
git remote add poky-contrib git://git.yoctoproject.org/poky-contrib | git remote add poky-contrib git://git.yoctoproject.org/poky-contrib | ||
Revision as of 14:43, 7 April 2015
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
- 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 remote repository:
git remote add poky-contrib 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/
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.