Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Contributing Documentation

If you want to help us improve our User Guide and other online documentation, please contact a Steering Committee Member and ask for editing permissions for our wiki space.

Contributing Code

If you have extended Jikes RVM and would like to contribute your extension back to the community, please use the patch tracker to submit your contribution. Please include the following:

  • Your contribution in the form of patches or bundles (see below)
  • The appropriate Statement of Origin
  • A description of the functionality you are contributing
  • The version of Jikes RVM used to create your patch

Your contribution will be licensed under the EPL (Eclipse Public License), the license used for Jikes RVM. The license has been approved by the OSI (Open Source Initiative) as a fully certified open source license. If your contribution is included in the system, you will be acknowledged on the contributors web page, along with getting the satisfaction of making the world a better place.

Please do the following before submitting your code contribution:

  1. Check that your contribution follows our coding style. One part of that is to make sure that there are no checkstyle failures when your changes are applied. You can run "ant checkstyle" to check for errors.
  2. After verifying that there are no checkstyle errors, run the pre-commit tests on your machine.
  3. After the pre-commit run is done, you can find the report at results/tests/pre-commit/Report.html. It should read something like "Total Success Rate: 128/128" (numbers from August 2012). The report will also display the revision number, if applicable. If the revision number ends with a +, you have uncommited changes in your working copy. Check that the uncommited changes are not supposed to be in your patch.

The Jikes RVM team will check for those points. You will make it easier to merge your contribution if you ensure that there are no problems in that regard.

Contributing patches

Patches should apply against a revision of the main repository. This ensures that your patch can always be applied easily. You can use hg export to create patch files from your commits.

Contributing bundles

If you contribute your changes in the form of mercurial bundles, you must make sure that the parent changeset of your first changeset is in the main repository. If it is not, hg unbundle will fail and your bundles cannot be imported.

Statement of origin

All contributions must include one of the Statements of Origin below. Insert your name(s) in the first blank(s) and a high-level summary in the blank in a (i) . Examples of a high-level summary are "Fixed bug in scheduler", "Extended type propagation in optimizing compiler", or "Added new garbage collector".

If your contribution is owned by your employer, someone authorized by your employer to make such a decision must add a comment to the patch in the tracker stating that you have permission to contribute it.

Statement of Origin: Single Contributor Single Contributor for all Contributions Multiple Contributors

  • No labels