Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
This section describes, and provides pointers to, the various aspects involved in code contribution to the ONOS project.
Getting ONOS source code
Developers should check out ONOS source, as per Getting ONOS - ONOS Source Code.
Licensing and Contributor Agreement
Any code contributed to ONOS source must be released under the Apache 2.0 license, i.e. the licensing information must appear in the header of contributed files. The IDE setup section describes how to configure the IDE to automatically add the licensing information for two IDEs, Eclipse and IntelliJ.
In addition, code submitters must agree to the project Contributor License Agreement (CLA), based on that of the Apache Software Foundation. The CLA may be found here.
Guidelines
To maintain a level of manageability in the codebase, the project maintains a set of coding and testing guidelines.
Coding style
The code style guide can be found here. Many IDEs may be configured to take care of the formatting aspects of the coding style.
Unit tests
Unit tests are a fundamental part of ensuring the stability of ONOS. Any new classes or system components should be accompanied by unit tests. For existing code, any changes that do not alter functionality should pass existing tests; however, existing tests should also be modified to reflect any changes that alter the behavior of a class or interface. Existing tests should not be disabled when new functionality is added, unless the tests are obsolete.
All available unit tests are run as part of a full build process. Contributions should pass all tests and build successfully before being submitted.
The full guidelines for unit tests can be found here.
Code Review
The ONOS project uses Gerrit for code review. Once submitted, a changeset is inspected by ONOS committers. The reviewers of a submitted patch, or changeset, depend on several criteria. For example, the reviewers for modifications to the existing codebase will likely include current maintainers of the particular subsystems that the changeset affects. Reviewers of new additions, e.g. applications, subsystems, and providers, will depend on where and how the new changeset will affect the existing codebase, as well as who, if any, has provided guidance during the development process of the changeset.
Feedback
The primary mode for feedback is via email. This includes notifications about changeset acceptance and rejection, as well as reviewer comments that should be addressed. Therefore, it is important to 1) be subscribed to the project, and 2) have email notifications configured in user settings. Git/Gerrit Setup addresses the configuration of Gerrit.
For a changeset to be accepted, it must receive one review with a +2 (not to be confused with two reviews of +1). A changeset given a -2 will not be accepted.
More information on Gerrit may be found here.
Code submission
The process of submitting code and amending changesets using the git Gerrit plugin is described in the next section.
Previous : Creating Issues
Next : Sample Gerrit Workflow