Apache
/
activemq-artemis
mirror of https://github.com/apache/activemq-artemis.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update hacking guide 

Update the Hacking Guide based on a recent conversation on the dev
list.
This commit is contained in:
jbertram 2015-06-25 14:13:36 -05:00
parent ab00b7c573
commit ed4200d65e
2 changed files with 30 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/hacking-guide/en/code.md
View File

@ -1,11 +1,16 @@
# Working with the Code
While the canonical Apache ActiveMQ Artemis git repository is hosted on Apache hardware at https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git
the developers use a mirror on GitHub for collaboration and pull-request review functionality.
contributors are encouraged (but not required) to use a mirror on GitHub for collaboration and pull-request review
functionality. Follow the steps below to get set up with GitHub, etc.
If you do not wish to use GitHub for whatever reason you can follow the overall process outlined in the "Typical
development cycle" section below but instead attach [a patch file](http://git-scm.com/docs/git-format-patch) to the
related JIRA or an email to the [dev list](http://activemq.apache.org/mailing-lists.html).
## Initial Steps
1. Create a github account if you don't have one already
1. Create a GitHub account if you don't have one already
http://github.com
@ -116,7 +121,7 @@ the developers use a mirror on GitHub for collaboration and pull-request review
1. Get your changes merged into upstream
1. Send a github pull request, by clicking the pull request link while in your repo's fork.
1. Send a GitHub pull request, by clicking the pull request link while in your repo's fork.
1. An email will automatically be sent to the ActiveMQ developer list.
1. As part of the review you may see an automated test run comment on your request.
1. After review a maintainer will merge your PR into the canonical git repository at which point those changes will
@ -137,7 +142,7 @@ the developers use a mirror on GitHub for collaboration and pull-request review
$ git fetch upstream
$ git pull
1. Pushing pulled updates (or local commits if you aren't using topic branches) to your private github repo (origin)
1. Pushing pulled updates (or local commits if you aren't using topic branches) to your private GitHub repo (origin)
$ git push
Counting objects: 192, done.

20
docs/hacking-guide/en/maintainers.md
View File

@ -3,6 +3,26 @@
Core ActiveMQ Artemis members have write access to the Apache ActiveMQ Artemis repositories and will be responsible for
acknowledging and pushing commits contributed via pull requests on GitHub.
Core ActiveMQ Artemis members are also able to push their own commits directly to the canonical Apache repository.
However, the expectation here is that the developer has made a good effort to test their changes and is reasonably
confident that the changes that are being committed will not break the build.
What does it mean to be reasonably confident? If the developer has run the same maven commands that the pull-request
builds are running they can be reasonably confident. Currently the [PR build](https://builds.apache.org/job/ActiveMQ-Artemis-PR-Build/)
runs this command:
mvn compile test-compile javadoc:javadoc -Pfast-tests -Pextra-tests test
However, if the changes are significant, touches a wide area of code, or even if the developer just wants a second
opinion they are encouraged to engage other members of the community to obtain an additional review prior to pushing.
This can easily be done via a pull request on GitHub, a patch file attached to an email or JIRA, commit to a branch
in the Apache git repo, etc. Having additional eyes looking at significant changes prior to committing to the main
development branches is definitely encouraged if it helps obtain the "reasonable confidence" that the build is not
broken and code quality has not decreased.
If the build does break then developer is expected to make their best effort to get the builds fixed in a reasonable
amount of time. If it cannot be fixed in a reasonable amount of time the commit can be reverted and re-reviewed.
## Commit Messages
Please ensure the commit messages follow the 50/72 format as described [here](code.md#commitMessageDetails).