] mean you commit code, it means you are committed to the project."
"Being a committer does not [only ] mean you commit code, it means you are committed to the project."
After the svn tag "beforeSvnRestructuring" the repository structure has changed, please refer to history for information before this tag |
The committers of OFBiz are those contributors who have the ability to commit changes into the OFBiz source code repository. As the project has grown over the years, there have been more committers of projects, so we thought it would be a good idea to define what the roles and responsibilities of the committers are. These points below are based on discussions we recently had on the developers' list:
Because OFBiz is a project of the Apache Software Foundation all OFBiz committers are Apache committers.
Once we have invited you to become a committer we need the following from you:
As you get into the swing of things, and get things initially setup for yourself, the following pages are helpful:
OFBiz is a community driven project, and the point of a community-driven project is to build software that would work in a large variety of situations with a large group of other people. Because of this it is really important that the project is written in a way which would benefit many potential users, and that the community works together towards that goal.
This is especially important for the commiters of the project to remember, since they would be making decisions not just for your own organization or your own clients, but for all current and future users of OFBiz as well. Thus, commit privileges carry with them a responsibility for "the greater good" of the project.
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. This is especially true if the change is just to make something easier for a particular client or customization effort. This means, in particular, that if some progress is made on a certain effort but you can't finish it in the time you have available, then don't commit it if it breaks anything that was there, just keep it local or attach it to a Jira issue or something if you want others to be able to get involved (or just get it to the point where the stuff it broke works again, then commit it).
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 read 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. This relates to respecting precedent. It doesn't mean that existing things can't or shouldn't be changed, but it does mean that things that already exist must be understood before they are changed. This also relates to recognizing that whatever you are doing chances are there are best practices or patterns already established. So, this means you should look for those and try to understand them and if necessary ask about them explaining what you are trying to do before you seek to establish your own pattern.
To avoid code ownership, anyone can work on anything, but please be sensitive to areas where you are not familiar with the code and check with others who have worked in the area before doing something. A good practice is to ask someone who is more familiar with something to review it before you commit it, and if they have objections respect it and find a compromise that works for everyone.
To become a committer, you should be highly familiar with OFBiz and should be actively involved in
If someone has stopped making new contributions for a while, we will contact them to find out why.
Committers are added by invitation only and that starts with a nomination from a OFBiz PMC (Project Management Committee) member. In order to be accepted as a committer the normal ASF voting pattern is followed. This basically means that 3 PMC members must vote in favor, and should there be any major objections they need to be addressed first.
So, as a prospective committer, how do I get invited, and what can I do in the mean time? Fortunately the answer to both of those questions is the same. Even if you are not a committer you can be actively involved in the development of OFBiz as a contributor. Here are some examples of things you can do to help out that will help the PMC notice you, and that will help you learn about OFBiz and get ready to become a committer:
The OFBiz project will next release 2 products: the framework (which for now includes applications) and the plugins. It is the responsibility of committers to maintain both products. So committers should checkout the framework and include the plugins using the Gradle pullAllPluginsSource. It is the also responsibility of committers to help fellow contributors to achieve a successful resolution of issues in JIRA. Committers should try, as much as possible, to avoid that patch files submitted to issues grow stale. It is a waste of effort and precious time on the part of a fellow contributor when patches grow stale, as rework needs to be done. Timely evaluation of patch files prevents the need for rework and re-evaluation. Showing interest in the work of fellow contributors builds better relationships and a healty community. When doing so, an efficient rule of thumb for productivity is the Ten minutes rule: if you can commit a patch in less than 10 minutes then just do it! Of course don't do that all the day long. Another important responsibility of a committer is participating in voting, especially the ones for new releases.. |
When committing changes, all committers should follow these general guidelines:
Committers should write a meaningful description of the feature being committed in the commit log so other developers and committers could understand what is happening.
|
Patches should never be used to move files. The diff and patch commands (even "svn di" and "svn patch") are unable to keep the information about moved files, only deleted and created. So we must not apply patches with files relocations. We not only lose history when doing so, but also annotations |
There are roughly 3 main types of changes:
Bug fixes should normally go in the release branches, as much as they can. Security fixes must trigger a new released packages.
New features and Improvements should never get into a release branch. Exceptions may occur, but they need a consensus, and as ever can be vetoed (only by committers, though this rule can be adapted by the community)
Unknown User (ccarlow) asked
Should committers download the entire ofbiz repository to help with backporting?
Here is Unknown User (jacopoc)'s answer:
It is easier if you keep the trunk and the release branches in different svn folders (i.e. different checkouts); for example:
mkdir ofbiz cd ofbiz svn co http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk svn co https://svn.apache.org/repos/asf/ofbiz/branches/release14.12 svn co https://svn.apache.org/repos/asf/ofbiz/branches/release13.07 svn co https://svn.apache.org/repos/asf/ofbiz/branches/release12.04 svn co https://svn.apache.org/repos/asf/ofbiz/site
You will end up with the following folder layout:
ofbiz/ ofbiz/trunk ofbiz/release14.12 ofbiz/release13.07 ofbiz/release12.04 ofbiz/site
Is there a standard procedure new committers should follow for backporting?
Here is a simple workflow to backport a commit to a branch.
1) commit the fix to trunk and note down the commit id; e.g. rev 12345 2) go to the release branch you want to backport to; e.g. cd ofbiz/release14.12 3) run the following script (the script will apply the commit to your local release branch): ./tools/mergefromtrunk.sh/bat merge 12345 4) run the tests with: ./tools/mergefromtrunk.sh/bat test 5) it is also a good idea to start the instance and test manually 6.a) if tests are unsuccessful, abort the process and clean your local release branch: ./tools/mergefromtrunk.sh/bat abort 6.b) if tests are successful, and you want to commit the backport: ./tools/mergefromtrunk.sh/bat commit
We tag deprecated services as a part of a release branch using the "<deprecated" element. Deprecated services will be removed from the next release branch when this new branch is created.
Lets say we set a service as deprecated for release branch R18. This service will be part of R18 and will be removed in next release branch R19.
For instance, imagine we decide to create a next to be released R19 branch.
We have on trunk :
When we create the R19 release branch, we change on trunk :
Before creating the new R19 branch we remove the services deprecated since R18. So the trunk contains only:
On this basis we create the R19 branch.
An so on...
To avoid confusion with other committers, when you take in charge a JIRA with a ready patch (Provide Patch button has been pushed) you should assign it to you and push the Start Progress button.
Please take the time to correctly fill the different Jira fields we now use for our releases change logs.
Critical - A feature of critical importance is faulty. A workaround is possible, or a quick fix could be applied after release. While you usually would not release with a critical fault present, it's conceivable.
For example at the moment the valid items for the Fix Version/s field are :
| As per our conventions, when the reporter or the assignee, or even another person who has reviewed, decides the issue is implemented, done or fixed (or any other resolution type) the issue should be CLOSED. |
After some time the following Jira reports will contain very useful information :
Change Log (what is available in released packages available from the Download page, this is not to be confused with the information given in our monthly blog posts)
| If the svn commits comments are correctly done, with a reference to the Jira issue number, we can then get to the commits in Fisheye from the Development section of the Jira issue. These can take a few days though... Also, please put the revision number in the Jira issue. That helps others doing research on changes. |
Here is a small documentation whith most aspects to know
The ASF has a Code of conduct, it's good to know and remember it. Though for miscellaneous reason you become a committer for life, please note this: "When somebody leaves or disengages from the project they should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off."