The OVS Development Process, with Kyle Mestery from IBM - a podcast by Ben Pfaff

Interview with Kyle Mestery, a Distinguished Engineer at IBM who has been
involved with Open vSwitch since about 2012, about the Open vSwitchdevelopment process. Our conversation was based onUpstream
Open Source Networking Development: The Good, The Bad, and the Ugly,
a presentation atONS
2016given by Kyle along with Justin Pettit from VMware and Russell
Bryant from Red Hat. Kyle also gave a version of the talk with ArmandoMigliaccio atOpenStack
Austin. The latter talk wasrecorded
on video.

The focus of the conversation is to present the Open vSwitch development
process by comparing it against the process forOpenStack NeutronandOpenDaylight. All three
project names begin with “Open,” but there are significant differencesin how they develop code!

How do these projects communicate? All of them have mailing lists,
although there are subtle differences in how they use them. Open vSwitchhas two main lists,ovs-discussandovs-dev. OpenStack,
despite being a much bigger project, has only a single developmentmailing list that it divides up using bracketed “topic tags” supported
by theGNU Mailmanmailing list manager. OpenDaylight, finally, has many mailing lists per
subproject. Kyle explains the advantages and disadvantages of eachapproach.

All of these projects have IRC channels also. Open vSwitch has a single
channel#openvswitchand the other projects have multiple,
subproject-specific channels.

OpenDaylight stands out as the only project among the three that relies
heavily on conference calls.

Are the projects friendly to newcomers? In general, Kyle thinks so. As
with any project, regardless of open or closed source, there will be someexisting developers who are super-helpful and others who are overworked
or overstressed and less helpful initially. In the end, how you cyclethrough leader and contributors in a project is how the project grows.

The projects handle bugs differently as well. Open vSwitch primarily
handles bugs on the mailing list. OpenStack files bugs inLaunchpadusing a carefully designed
template. OpenDaylight has aBugzillainstance and awikiwith
instructions and advice. Kyle thinks that Open vSwitch may need to makeheavier use of a bug tracker sometime in the future.

The projects have different approaches to code review. OpenDaylight and
OpenStack useGerrit, a
web-based code review system, although many developers do not like andavoid the Gerrit web interface, instead using a command-line tool calledGertty. Open vSwitch
primarily uses patches emailed to the ovs-dev mailing list, similar tothe Linux kernel patch workflow. In-flight patches can be monitored viaPatchwork,
although this is only a tracking system and has no direct control overthe Open vSwitch repository. Open vSwitch also acceptspull requestsvia
Github.

Kyle mentions some ways that the Open vSwitch development process might
benefit from approaches used in other projects, such as by assigningareas to particular reviewers and dividing the project into multiple,
finer-grained repositories. OVN, for example, might be appropriate as aseparate project in the future.

Kyle's advice: plan ahead, research the projects, give your developers
time to become comfortable with the projects, treat everyone withrespect, treat everyone equally, and give back to the core of the
project. Keep in mind that little maintenance patch are as important ashuge new features. Finally, trust your developers: you hired good
people, so trust their ability to work upstream.

The interview also touches on:

• How Kyle became involved with Open vSwitch when he was a software
  engineer at Cisco and how his role at IBM has shifted a little moretoward management.
• The “Wild West” explosion of open source software in networking in
  the last few years.
• The four stages of how companies get involved in open source networking
  projects: excitement, panic, enlightenment, success. The key toenlightenment, Kyle says, is that you get out what you put in, which
  includes a “karma cycle” of helping to get other developer's code in,e.g. through code review.
• The importance of giving developers credit for putting time into
  reviewing and testing code, and how different projects do it, plus thepitfalls in using karma-like systems that can be gamed to the point of
  becoming “poisonous.”
• “Onboarding” in projects and how a developer becomes a “core team”
  member or “committer.”

You can reach Kyle as @mesteryon Twitter and follow his blog atsiliconloons.com.

OVS Orbit is produced byBen Pfaff. The
intro music in this episode isDrive,
featuring cdk and DarrylJ, copyright 2013 by Alex. The bumper music isYeah Antfeaturing Wired Ant and Javolenus, copyright 2013 by Speck. The outro
music isSpace
Bazookafeaturing Doxen Zsigmond, copyright 2013 by Kirkoid. All content is licensed under a Creative CommonsAttribution 3.0
Unported (CC BY 3.0)license.

Further episodes of OVS Orbit

Further podcasts by Ben Pfaff

Website of Ben Pfaff