Difference between revisions of "Submitting Contributions"
Revision as of 17:48, 24 August 2013
As webOS Ports is a community project we're very happy about accepting patches. But there are some things you have to know before and to respect when submitting patches.
The process is only for components hosted on the webOS ports github project (http://github.com/webOS-ports) and are specific to webOS ports. For contributions which belong to the Open webOS project please read the guideline at How We Accept Contributions.
How We Accept Contributions
The Contribution Process
For big changes, the contributor communicates with the Project via mailing lists or Bug Tracker tickets to get feedback before submitting code
- Contributor adds signoff line to each commit message during development
- Contributor makes a GitHub pull request (see https://help.github.com/articles/creating-a-pull-request)
- Maintainer conducts code review, verifies signoff, runs tests and asks for adjustments from contributor as necessary
- Maintainer merges the commits into the repo and closes the pull request
Criteria for Making a Pull Request
- Contributor has verified that their changes do not break any of the builds
- Contributor has provided or updated unit tests, if there is an existing unit test structure for any of the components affected
- If there is no unit test structure, the contributor has thoroughly tested their changes manually, and can describe the results
- Code is in the style of the code that surrounds it
- Contributor has followed the commit guidelines
During Review the Maintainer Will:
- Look to see that your signoff is in all your commit messages, including format, and presence of real name and real email address
- If you are someone entirely new to the Project, they may get in touch with you via the contact information you have provided
- If there are anomalies such as inconsistent name or email address between signoffs, they may ask you to clarify
This process may take some time, since we may conduct testing, and there may be concurrent activity which must be checked for merge conflicts, architectural issues, etc.
What You Will See Once Your Pull Request Has Been Reviewed and Accepted:
- Your commits will be merged onto the master branch, with your SHA-protected signoff included
- The maintainer's identity who accepted your pull request will be recorded in the merge
- The pull request will be closed
Congrats, your contribution is in!
If Your Existing Pull Request Contains Commits that Don't Have the Signoff:
One way you can fix this:
Assuming no one has forked from your fork, or you don't mind breaking them use "rebase -i" to edit the existing commit messages (Google it) Open a new pull request with the fixed commits Close the existing pull request, with a comment showing the new one that it has superseeded.