This project welcomes new contributors and invites everyone to participate. Our aim is to build an open community. There are many different ways to get involved:
People that help with the project in any of the above categories or other ways are contributors. See the roles as defined by the ASF.
Community members that make sustained, welcome contributions to the project may be invited to become a committer. Committers are voted in by the PMC. A committer has a signed Contributor License Agreement (CLA) on file and an apache.org address.
We expect committers to subscribe to the project mailing lists.
A committer will be considered “emeritus/inactive” by not contributing in any form to the project for over 1 year. An emeritus committer may request reinstatement of commit access from the PMC. Such reinstatement is subject to lazy consensus of active PMC members.
The Project Management Committee (PMC) is responsible for the oversight of the project and it also decides who to add as a PMC member. Existing committers may be invited to become a PMC member after consistent contribution and activity over a period of time and participation in directional and community building discussions.
Apache Apex follows coding style that is closest to K & R style and uses Checkstyle tool to enforce these standards. Travis CI will fail for any pull request that introduces any style violations.
The checkstyle configuration that Apache Apex projects use is present here : https://github.com/apache/apex-core/blob/master/apex_checks.xml
To make it easier for the users to set up their development environment, settings for the following common IDEs are provided in the Apache Apex Core repository with instructions.
The apex-core and apex-malhar repositories both have mirror repositories on github which are used to review pull requests and provide a second remote endpoint for the codebase.
git clone https://github.com/{github_username}/apex-core.git
git remote add upstream https://github.com/apache/apex-core
APEXCORE-123.my-feature
.git checkout -b APEXCORE-123.my-feature -t upstream/master
git branch -u upstream/master
mvn license:check -Dlicense.skip=false
to check correct header formatting.mvn license:format -Dlicense.skip=false
to automatically add the header when missing.master
.@
notation in Github comments to mention that user, and request that he/she reviews your changes.mvn checkstyle:check -Dcheckstyle.console=true
and correct those issues that were introduced with your changes.If tracking upstream/master then run git rebase -i
. Else run git rebase -i upstream/master
.
This command opens the text editor which lists the multiple commits:
pick 67cd79b change1 pick 6f98905 change2 # Rebase e13748b..3463fbf onto e13748b (2 command(s)) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # These lines can be re-ordered; they are executed from top to bottom.
Squash ‘change2’ to ‘change1’ and save.
pick 67cd79b change1 squash 6f98905 change2
master
substantially. Therefore, it is recommended to frequently merge master
to the branch being worked on by:git pull
git pull upstream master
master
results in a conflict then resolve it and commit the merge. This results in additional merge commits in the pull request. Following steps help to ensure that the final pull request contains just one commit:git branch -m APEXCORE-123.my-feature.squash
git checkout -b APEXCORE-123.my-feature -t upstream/master
git merge --squash APEXCORE-123.my-feature.squash
git commit -m "APEXCORE-123 #comment added my-feature"
git push origin +APEXCORE-123.my-feature
git branch -D APEXCORE-123.my-feature.squash
Thanks for contributing!
https://git-wip-us.apache.org/repos/asf/apex-core.git
dev@apex.apache.org
mailing list to see the exact commands to merge the given pull request.master
branch. Within a few seconds, the changes will propagate back to the github mirror and the pull requests be closed and marked merged automatically.Fix version
field on the corresponding JIRA ticket needs to be set and the ticket resolved after pushing the changes.Note: since none of us has write access to the mirror, only the author of a pull request can close it if it was not merged.