Skip to content

Latest commit

 

History

History
54 lines (40 loc) · 3.75 KB

CONTRIBUTING.md

File metadata and controls

54 lines (40 loc) · 3.75 KB
Raw

Contribute to GeoTools

When submitting a patch or pull request:

  • Small Contribution / Single Source Code File: For a very small change (less than one file) a committer can review and apply the change on your behalf. This is a quick workaround allowing us to correct spelling mistakes in the documentation, clarify a javadoc, or accept a very small fix. We understand you may have to update several test cases to verify your change fixes its intended problem.

  • Large Contributions / Multiple Files / New Files: To contribute a new file, or if your change effects several files, sign a Code Contribution License. It does not take long and you can send it via email.

For details check the developers guide page on contributing.

Code Contributions

Regardless of what you want to achieve, there are some common steps to consider:

  1. Talk first policy

    Unless you intend to provide a trivial change (fixing typos in the documentation, easy bugfix with test) the very first thing you should do is to subscribe to the GeoTools developer list and explain what you're about to do.

    This is a very important step:

    • It lets core developers assess your suggestions and propose alternate/better ways of getting the desired results
    • It makes it easier to review the pull request/patch as its content are already known and agreed upon

  2. Create a local branch:

    git checkout -b fix_featureLock

  3. Work on the fix, using commit as needed.

    • Please remember to always include a test case, most pull requests/patches will be rejected if they don't contain one..
    • Please make sure you're following the coding conventions, and otherwise avoid any reformats to the existing code, as they make it harder to review your changes. If you find sections not following the coding convetions and you want to amend their formatting, that's fine, please do so in a separate commit/patch from the real code changes.

  4. Review the work that was done, make sure the changes contain all the files you need, and no other extraneous change:

    git status

    In case you're making a pull request, single commit ones are preferred, you can use rebase -i to squash multiple commits into one, it's fine to have two commits if one is used to isolate code formatting changes

  5. Rebase the branch from master so you get a nice clean set of changes:

    git pull --rebase master

  6. Do a full maven build (with tests) to make sure your fix compiles cleanly:

    mvn clean install -Dall
    • Don't break the Build: We do have this nice rule about breaking the build (don't). This means that if you are working on core interfaces you will be running all over the place cleaning up modules. One very good reason to talk to the list first is to give other module maintainers a chance to get out of the way, or offer to help you clean up the mess.
    • Master First: Changes cannot be accepted directly onto the stable branch, they need to be tried out on master first. We are able to accept fixes and changes that do not break compatibility onto the stable branch after they have been tested on master.

  7. Submit pull request: for instructions on submitting a pull request see Using Pull Requests on GitHub.

    Pull requests are reviewed by module maintainers as outlined in our developers guide page on pull requests.