ONAP Open Source Practice Codifying Upstream First with Lessons from OpenDaylight, OPNFV and OpenStack Marcus Williams - Intel Dec 12 , 2017

Err on the side of too much communication ONAP is a Cross-Geo, Multi-Team, Multi-Company, Multi-Time-zone, diverse set of people with varying skill levels working in concert to develop and release a very complex Open Source platform and set of software built on other Open Source software that is developed by an even larger set of Cross-Geo, Multi-Team, Multi-Company, Multi-Time- zone, diverse sets of people What could go wrong? We prevent things going wrong by communicating often and with vigor: Asynchronous Communication Email Lists Gerrit Synchronous Communication IRC

https://lists.onap.org (Email Lists) When in doubt, send it out (cc’ed to the list) Keeps people in the loop with minimal effort Creates a record of discussions, decision points and troubleshooting Encourages others to participate in said issue, bug, feature, discussion In Open Source, Siloed conversations = BAD Siloed conversations encourage duplication of effort Siloed conversations create knowledge desserts and concentrate understanding among a few Rare instances where list should not be used Siloed conversations: Examples of non-list conversations: Sensitive discussion between committers/PTLs

Insert Synchronous Communication Tool Name Here Use public synchronous communication for immediate communication or communication that doesn’t merit sending to the list Synchronous communication builds the team Again, Siloed conversations = BAD Rare instances where private <Insert Synchronous Communication Tool Name Here> should be used Pick a tool and standardize IRC? Slack? HipChat? Does your company block said tool? Become and evangelist to get them to see the light.

Gerrit As Code Merge Record Constraint – All code review on a specific change is kept in one gerrit review (more on this later) Gerrit can be used as code merge record Historical Record Why did this code get in? (It introduced a bug that brought down the whole process…) Learning tool for future contributors Learn process of committing Learn the type of code wanted by committers Facilitates blaming the person who broke it (Just kidding, kind of) Eases rollback when things go wrong

Everyone is a Code Reviewer Everyone can contribute to code reviews Commit Process (commit message standards, keeping reviews in the same gerrit review, documentation) General good coding practices Internal Consistency of a chunk of code Even +1 with no comments is helpful Positive comments are also useful – “+1 – I really liked your use of recursion here.”

+2, +2, +1 is the new +2? Higher standards for merging code = Better code? Higher standards have higher cost Probably produce better code Varying standards used to merge code across open source projects: OpenStack Kolla requires +2, +2, +1 Often resolves as two committers +2 and one contributors +1 OpenDaylight Integration requires only +2 but committers often wait for another +1 or +2 before merge

Dummy's Guide to Reviewing with Gerrit Reviewing has high cost At each chance encourage contributors to make smaller manageable contributions to facilitate easy, thorough and quick review If pressured for time reduce time cost by turn reviewing process into iterative process Review patch to find two or three issues and post constructive comments about issues Wait for contributor to update patch Review patch again Rinse and repeat until patch is ready for merge Keep each code contribution on a single subject in the same gerrit review Discourage contributors from abandoning patches, to push new patches when they are just updating to address feedback from a review Usually a side-effect of lack of knowledge of git or the review process Higher cost for committer, as they don’t have review history to inform review -1 or -2 Stops review process until updates from contributor

No Self-Commits No Self-Commits (In case of emergency self-commit) Self-Committing is BAD for Open Source It single handedly defeats one of Open Sources greatest strengths: Code Review If you are thinking about self-committing – ask yourself these questions: 1) Have I tried to contact all of the committers who could merge this? 2) Is it absolutely urgent that I get this code in right now?

Upstream First. What's that? Code should be submitted upstream as early as possible in the development cycle so that feedback can be given and direction adjusted to adhere to project standards and code feedback The original author(s) of the code should be involved in the process and modify code to fit upstream standards, practice and feedback The author of the code should contribute and interact with the project/community where his code is pushed – ensuring a healthy community and give/take balance

ONAP is littered with committers Seriously. Approved Project pages are filled with committers from project creation but only a few on each project are active We should remove excess committers to make room for merit based promotions In the future we should be very careful about committers in project proposals

Hey, I have Committer Issues (duties) Participate in meetings Show up Take meeting minutes Have an opinion Review code Make sure project process is followed (commit messages, keep commits in single gerrit, engender knowledge of the process) Become an expert in an area of the code and be a rockstar reviewer for that area Make constructive comments and explain how contributors can fix issues Help document the process Document how the project team works in gerrit, wiki, email lists, in person Submit Code Help Develop across the project (no just your assigned silo) Role model code submission practices Fill in the gaps Help the PTL by volunteering Make sure nothing is missed by the project

What happened in that meeting? I was bungee jumping… Projects should take weekly meeting minutes and cc the list An Open Source project’s discussions, decisions and meetings should be documented and openly available One off meetings should also be summarized and sent to the list by a participant Lowers bar to entry for new contributors Allows others outside the project to stay abreast of projects status, discussion and decisions and to contribute when warranted Documents project decisions and facilitates future review for project participants Serves as a resource for those who miss project meetings

Learn from Projects that Came before None of the issues ONAP faces are new Let’s look to other Open Source Projects as a guide to extending and improving ONAP open source practices

Thank You Marcus Williams – Network Software Engineer – Intel IRC: mgkwill Twitter: mgkwill Web: www.mgkwill.com