...
- Follow coding conventions. Make sure that your files do not have tabs where they should have spacesSeriously, ready that document.
- Install the OFBIZ Subversion client configuration file
- Follow the 2 main rules for committers:
- Rule #1 for a committer is the same as for a doctor: first do no harm. Nothing should be committed that breaks existing functionality without replacing it either before or in the same commit. Whatever you are working with someone developed it and chances are someone is using it, and possibly MANY people.
- Rule #2 for a committer is the same as for a scientist: read before you write*.*When you're getting started a good time ratio for reading to write is around 20 to 1. Once you're a total OFBiz pro who knows as much as any living person about the project, you can probably reduce that to about 3 to 1.
- Discuss your features with the community. What are you trying to implement, and how are you planning to do it? This is especially important if you are new to the project.
- Write clear, well-commented and understandable code. Don't take shortcuts, especially around variable names and error or warning messages. Use understandable data structures. Remember, somebody else will be working with your code down the road.
- When you prepare a patch, do your best to avoid to mix formatting changes with relevant changes (if possible, provide a separate patch containing only formatting changes): in this way the reviewer's work will be easier
- When you prepare a patch, do not insert in the code comments with author information since your name will be recorded in the commit log (that is the place were we store this kind of information)
- Internationalize your code with UI labels.
- Start out with small contributions which are easier to review. In the process, get familiar with the project's coding style and "thought process."
- Keep patches and contributions easy to review and commit. Even if a lot of code is touched, try to keep things isolated and the intent of the patch(es) clear. Remember that most committers can find 20 minutes here and there, but it is very hard to fit in the 2-4 hour time block required to review and commit a larger patch (especially if it touches ANY lower level or more sensitive or complex artifacts, and this requires more thorough review).
- Put your contributions on JIRA instead of emailing it directly to the committers, so everybody can review and comment on it. Though it is not necessary this makes contributions more traceable for the licensing through the Apache Software Foundation.
- Get other members of the community to try your patch. Write the dev list and tell them what you've done and ask them to try it out and vote for it. This will help the committers when they are reviewing your patches as there will be more confidence that the patch does what it is intended to do, and doesn't break anything else.
...
Then, send in a patch file. This is a file which will describe all the differences between your modified code and the code in the OFBiz Subversion repository. You can create a patch file by using a command like this:
| Code Block |
|---|
$ svn diff applications/product > product.diff |
...
Make sure that the from/current revision of your local sandbox (checkout) is the current revision, or a very recent one, from the OFBiz SVN repository. The local revision can be checked by doing:
| Code Block |
|---|
$ svn info |
To make sure you have the most recent revision always do an SVN update before doing the patch with svn diff, something like this:
...