Page History

...

• 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-dev 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 weekly TST meetings. Preferably, this should be done through onos-tech-steering-team mailing list. 
  • Examples of previous feature proposals are available and may help as a template
  • Technical discussion on the Slack channels can also be conducted.
  • The reason for this interactive phase is to make sure that the proposal is properly aligned with ONOS architecture & technical direction, that it conforms to the overall software design and that the abstractions are properly formed.
  • For larger submissions, the technical steering team would also coordinate with the release planning team to decide which ONOS release the submission should join.
  • For larger submissions the release planning team would also need to determine what support resources will be available for the new features or subsystems.
  • Jira Epic or User Stories would be formulated during this part of the process, for tracking the features and associated activities as part of the identified ONOS release.
• 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.
  • Code-style and Javadoc guidelines should be followed in order to maintain code consistency and quality of documentation.
• 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, or many small concurrent reviews, leads to longer review cycles.
  • Code-style guidelines and unit test guidelines should be followed in order to maintain code consistency and code quality.
  • Code submissions must be accompanied by unit tests with assertions of expected behaviour and sufficiently high code coverage; minimum coverage is 70%, but goal is 80%+.
  • Care should be taken not to negatively impact the overall system performance and stability.
  • Jira sub-tasks can be used to track progress and to give visibility of the work to the rest of ONOS community.
  • If applicable, features should have CLI & debug support.
  • Submitter is responsible of maintaining code up to date with the master until the change-set has been committed to the codebase.

...