Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

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

Compare with Current View Page History

« Previous Version 23 Next »

The committers of OFBiz are a core group of developers 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:

Apache Software Foundation Committer Information

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:

  • An Individual Contributor License Agreement (iCLA) on file with the ASF (see iCLA text document)
  • If you are employed we may also need a Corporate CLA in addition to the iCLA (see cCLA text document)
  • Once we have these filed it will be time to get your account created on people.apache.org, for this we need from you:
    • your preferred userid, plus an alternative or two
    • your full name, as listed on your iCLA
    • your forwarding email address, needs to be the same as on your iCLA

As you get into the swing of things, and get things initially setup for yourself, the following pages are helpful:

General Responsibilities of Committers

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.

Becoming a Committer

To become a committer, you should be highly familiar with OFBiz and should already have had a significant number of contributions accepted into the project.

Committers should be actively involved in contributing new code AND in reviewing patches and answering questions from the community. 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:

  1. Subscribe to the dev mailing list, try to read the majority of the messages, and participate in discussions there
  2. Review and comment on issues in the Jira issue tracker
  3. Apply patches from Jira locally and test them and comment on the results
  4. Create patches to fix issues reported in Jira
  5. Get to know OFBiz and submit patches to fix problems or annoyances you find
  6. Follow the advice and do all of this according to the recommendations in the Contributors Best Practices document

Committing Changes

When committing changes, all committers should follow these general guidelines:

  1. Committers should set up their SVN client to use the official OFBIZ Subversion client configuration file
  2. Committers should review contributions to ensure that they follow good coding standards, are well-commented and understandable, and follow our coding conventions
  3. 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.

    Here are some commit comments examples of badness taken from an Adam's message in dev ML

    • Fixed bug (reported by $user)? from $location.
      When reading history, the full discussion leading up to a proper bug fix is not important. But a description of the bug, and the solution, are nescessary.
      Quite often, when trying to find a bug, the original sources are not available. All you have at your disposable is the installed system image. The changelog describing the software installed very often accompanies the installation. It's quite possible that no outside access is available. Embedded system deployments do this quite frequently.
      When scanning a changelog for possible hints into why something is/isn't working, if I have to switch back and forth from the target system, and an external system, to figure out what is going on, then it will leave a sour taste in my mouth. Going forward, I would be reluctant to recommend the software again.
      Additionally, no one is you. There are 6 billion other people on this planet, and you are the only one who knows what you are thinking. We can't read minds. It becomes even more difficult to do so, 2-3(or more) years in down the road. So, describe what you have done at the time you have done it.
      Also, not everone knows how jira works. Or confluence. Or AutoConfigMaintenceWidgetApplication. What you may thing as a sensible cross-reference(OFBIZ-####, debbugs ####) may mean nothing to the person reading your changelog.
    • I did some things in FooClass, FooImpl, some more stuff in BarWidget, and yet more interesting tidbits in YellowSubmarine; basically, stuff all over the place.
      This bad changelog is not about poor descriptions of the changes. It's about listing multiple, 100% completely separate improvements/fixes into a single commit.
      If there were 10 lines changed, and 1 line was not related, it's possible that you could still notice that 1 extra line. But if you have 1000 lines changes, and there are 3 groups of changes, and theyare all intermingled, it becomes very difficult to very that each separate change was actually implemented correctly.
      It's much better to split up such changes, and commit them separately. There are several ways to do this. svk/hg/git can be used to mirror svn, have local changes, then push when you are done. You can use multiple svn checkouts, and redo your changes, one step at a time.

In addition, all committers must do the following to ensure licensing compliance:

  1. Make sure the contribution is posted publicly on the Apache OFBIZ JIRA issue tracker. Please do not commit changes that were sent to you privately. If you receive a patch, open a JIRA issue and then ask the submitter to post his patch there. This way, we can avoid having to get an iCLA for the contributor, as well as let everybody in the community view and comment on the contribution.
  2. If it is a new file, the file must have the Apache 2.0 license header.
  3. The commit log must identify the name of the contributor and, if relevant, the JIRA issue for it.
  • No labels