Have questions? Stuck? Please check our FAQ for some common questions and answers.

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

Compare with Current View Page History

« Previous Version 2 Next »

What is a Module Owner?

The ONOS codebase is composed of different modules, and people have been given responsibilities over each of those modules.  A "Module owner" is someone who can give a +2 review for a particular part of the codebase and submit code in that area. 

Owners are responsible for maintaining the quality of contributions for their part of the codebase, and owners who are not performing their responsibilities will receive an initial warning and then may lose owner status.  Benefits of being an owner include getting to influence the direction of the project through reviewing other people’s code, not having to wait to have their own code reviewed and receiving recognition for their expertise over the code.

A list of Module Owners is available on Gerrit (note that you need to be logged in to access this list).  You can also find the list from the Gerrit UI: Projects -> List -> onos -> Module Owners.

Becoming a Module Owner

To be a good candidate for a Module Owner, you need to have a demonstrated proficiency with part of the ONOS codebase and a track record of code reviews.  Members of the Technical Steering Team and existing Module Owners will regularly invite people to become new Module Owners.

Nominations for new Module Owners can also be submitted to the Technical Steering Team mailing list.  A good nomination will include details about who the person is and what their experience is with a specific area of the codebase. Nominations are intended to start a conversation that results in a decision about granting or not granting ownership – anyone who isn't granted ownership initially is encouraged to gain more experience with code submission and code review in order to gain further mastery over the codebase.

Tips for Modules Owners

Keep an eye on the big-picture as well as on the more cosmetic stuff.  It’s harder to spot inefficiencies in the mid-level designs, but the good news is that as long as things are properly compartmentalized and not entangled (from the big picture), the mid-level stuff can be addressed individually if something less-than-ideal slips through.  Please feel free to also provide feedback on other areas of code outside your designated area - all help is welcome - and conversely, if something falls in your area, but you’d like a second opinion, just +1 and make sure other reviewers are on the list. If you ever have any questions about what to do, please ask on the TST mailing list.

Gerrit Plug-in

There is a Gerrit plug-in that is used to help manage the Module Owner review process.  Functions of the plug-in include:
  • An interface to enable new owners to +2 patchsets and submit them when they fall within their module(s).
  • Code reviews from module owners are highlighted using the Module-Owner label (in addition to the Code-Review label). If you are a module owner for a particular change, this label will automatically track any code review scores. 
  • When new changes are uploaded, the plugin will identify the 2 "best" module owners according to the following criteria: number of files owner, then length of matching prefixes, then random. This is to help module owners identify changes that they own. Module owners should not feel like they are required to review every change for which they are assigned. Owners are welcome to remove themselves from the change and/or add another person that they think would be better suited to perform the review.

If you are interested in the code for the plugin, need to file a bug or want to help improve it, it is available here: https://github.com/bocon13/moduleowner

  • No labels