|
We're always looking for contributions! Here are some ways to participate in Cargo's development:
- By sending feedback to the mailing lists. The feedback could be about something that does not work, something that could be improved, a feature you'd like to see, etc. Or simply it could be that you're a happy user. Letting us know helps a lot!
- By answering emails from others on the mailing lists.
- By sending code patches. In that case there are a few rules you need to know.
- By spreading the word about Cargo!
Creating and submitting a patch
When you have either completed an issue or just want some feedback on the work you have done:
- Propose any patch / pull request using Github's standard processes
- This will automatically create a build on the Continous Integration system, which covers:
- Build with the latest JDK and Maven versions.
Note that this automatically checks various other things too - For example code formatting.
- Build with the lowest JDK and Maven versions supported by Codehaus Cargo.
- Integration tests on all publicly downloadable containers.
Patch acceptance criteria
There are a number of criteria that a patch will be judged on:
- Whether it works and does what is intended. This one is probably obvious!
- Whether it fits the spirit of the project. Some patches may be rejected as they take the project in a different direction to that which the current development community has chosen. This is usually discussed on an issue well before a patch is contributed, so if you are unsure, discuss it there or on the mailing lists first. Feel free to continue discussing it (with new justification) if you disagree, or appeal to a wider audience on the mailing lists.
- Whether it contains tests. It is expected that any patches relating to functionality will be accompanied by unit tests and/or integration tests. It is strongly desired (and will be requested) for bug fixes too, but will not be the basis for not applying it. At a bare minimum, the change should not decrease the amount of automated test coverage. As a community, we are focusing on increasing the current coverage, as there are several areas that do not receive automated testing.
- Whether it contains documentation. All new functionality needs to be documented for users, even if it is very rough for someone to expand on later. While rough is acceptable, incomplete is not. As with automated testing, as a community we are striving to increase the current coverage of documentation.
Above all, don't be discouraged. These are the same requirements the current committers should hold each other to as well.
And remember, your contributions are always welcome!
Coding rules
If you submit a patch you need to follow these rules:
- Copyright your code to Ali Tokmen (see license explanations)
- Do not use an
@author tag (there was a big discussion on this in Apache land - We need to put the link here)
- Ensure that your code passes the build. Note that the build contains some Checkstyle checks that your code must pass.
- Ensure that you have unit tests and/or integration tests (as part of the existing Cargo test suites).
- Use the same code formatting as the existing code.
- Either:
- Create documentation for what you have added (Ask on the list and you'll get access to Cargo's wiki).
- Add your name on the Credits page.
In addition if you plan to contribute big patches that impact existing code, we recommend discussing it on the mailing list first.
Thanks! |
