Page History

...

Suggested Process Outline

Developers are encouraged to build on ONOS and, as much as possible, to contribute their enhancements back to its code base. The ONOS team strives to provide the right balance between enabling and encouraging innovation and creativity, but at the same time maintaining the coherency of ONOS architecture and the code. To that effect, we welcome partners and contributors to follow the process outlined below:

• Explore and prototype your ideas freely atop the ONOS code-base.
  • We encourage doing this via quick proof-of-concepts exercises to vet out feasibility and test the concepts, but without investing much effort beyond that.
  • If possible, advertise on onos-discuss mailing list for feedback and potential collaborators.
• Formulate a brief proposal in writing to the TST using the onos-tech-steering-team mailing list.
  • If person-to-person discussion is desired, it is suggested to put the item on the agenda for the bi-weekly TST meetings.
  • Technical discussion on the IRC channel can also be conducted.
  • Jira Epic or User Stories would be formulated during this process, for tracking the features and associated activities.
• Submit new or changed Java APIs for review via Gerrit. 
  • It is suggested to use Java interfaces rather than Java classes as this forces the discussion to revolve around the semantics of the contract, rather than implementation specifics. If appropriate, interfaces can easily mutate into classes later.
• Adjust the Java APIs based on the feedback from the TST and from the broader ONOS community.
• Proceed with implementation and submit code for review via Gerrit.
  • Preferably, this can be done in fairly small and discrete chunks. In our experience, dropping large chunks of code for review leads to longer review cycles.
  • Code-style guidelines and unit test guidelines should be followed in order to maintain code consistency and code quality.
  • Jira sub-tasks can be used to track progress and to give visibility of the work to the rest of ONOS community.
  • Submitter is responsible of maintaining code up to date with the master until the changeset has been committed to the codebase.

Clearly for bug fixes and small enhancements, the above process can be significantly abbreviated. However, for larger feature contributions, following this process will greatly increase the chances of success and should make for a smooth experience overall. We look forward to your contributions and to see what exciting ideas and solutions you can build with ONOS!

Getting ONOS source code

Developers should check out ONOS source, as per Getting ONOS - ONOS Source Code.

...