Daniel Farrell
Software Engineer, Red Hat SDN Team
BEST PRACTICES FOR ENGAGING IN UPSTREAM PROJECTS
Daniel Farrell
dfarrell07
Red Hat SDN Team
@dfarrell07
VERY QUICK: INTRO TO ME
Daniel Farrell
Software Engineer, Red Hat SDN Team
VERY QUICK: INTRO TO ME
PTL:
-
OpenDaylight Integration/Packaging
- OPNFV CPerf
VERY QUICK: INTRO TO ME
Committer:
- OpenDaylight Integration/Test
- OpenDaylight RelEng/Builder
- CentOS NFV SIG
VERY QUICK: INTRO TO ME
ex-OpenDaylight TSC
VERY QUICK: INTRO TO ME
OpenDaylight Board
Overview
OVERVIEW
What is 'upstream'
OVERVIEW
Upstream structures
OVERVIEW
How open source enables upstream
OVERVIEW
Mechanics of engaging upstream
OVERVIEW
Best practices for working upstream
Overview
Help us help you
Upstream?
Upstream?
What is 'Upstream OpenDaylight'?
UPSTREAM
Globally distributed community of contributors
UPSTREAM
Many interests, collaborating on one project
UPSTREAM
Devs, test, leaders, users, events staff, related communities
Upstream Structure
Linux Foundation
LINUX FOUNDATION
Provides infrastructure
(Gerrit, Jenkins, Nexus, Bugzilla, mailing lists...)
LINUX FOUNDATION
Organizes events
(Dev Design Forum, Summit, Mini-Summits)
Projects
PROJECTS
OpenDaylight is made of many projects
PROJECTS
Anyone can submit one
PROJECTS
TSC* vets and approves new projects
*Details later
PROJECTS
May or may-not take part in Simultaneous Releases
(no shame! my projects don't)
Contributors
CONTRIBUTORS
You!
CONTRIBUTORS
Everyone can contribute
CONTRIBUTORS
No approval required, no company affiliation required
CONTRIBUTORS
Create a LF ID and start pushing
CONTRIBUTORS
Code, docs, bug reports, teaching, advocacy, etc
Committers
COMMITTERS
Contributors who review code
COMMITTERS
Elected by other committers, approved by TSC*
*More soon
COMMITTERS
Responsible for deciding direction of projects
COMMITTERS
Vote for PTLs, TSC/Board Committer-at-Large seats
Project Tech Leads
PROJECT TECH LEADS
Project-level governance
PROJECT TECH LEADS
Follow release process
PROJECT TECH LEADS
Interface with other projects, TSC
PROJECT TECH LEADS
Elected by committers
PROJECT TECH LEADS
Vote on TSC Project-Type Represented Group seats
Technical Steering Committee
(TSC)
TECHNICAL STEERING COMMITTEE
Elected by community, not appointed by companies
TECHNICAL STEERING COMMITTEE
Seats allocated to Represented Groups
TECHNICAL STEERING COMMITTEE
Community-wide discussions
TSC
Release process
TSC
TSC-level cross-project interactions
TSC
Approves new projects
TSC
Approves project committers
TSC
Interface with external groups
(OPNFV)
TSC
Suggests priorities
TSC
Hard problems end up here
OpenDaylight Board
OPENDAYLIGHT BOARD
Board-level cross-community collaboration
OPENDAYLIGHT BOARD
Gives TSC powers
(writes TSC charter)
OPENDAYLIGHT BOARD
Events
OPENDAYLIGHT BOARD
User Advisory Group
OPENDAYLIGHT BOARD
Financial and legal boring stuff
ENABLER: Open Source
ENABLER: OPEN SOURCE
More than a license, mostly community
ENABLER: OPEN SOURCE
License enables collaboration
Types of Open Source Communities
TYPES OF OPEN SOURCE COMMUNITIES
Loosely Aligned
TYPES OF OPEN SOURCE COMMUNITIES
Vendor Dominated
TYPES OF OPEN SOURCE COMMUNITIES
Foundation Manged
Open Source: Loosely Aligned
OPEN SOURCE: Loosely Aligned
Most common
OPEN SOURCE: Loosely Aligned
Rarely become popular
OPEN SOURCE: LOOSELY ALIGNED
Some miraculous successes
(Linux, GNU tools...)
OPEN SOURCE: LOOSELY ALIGNED
Some transition into Foundation Managed
OPEN SOURCE: Vendor Dominated
OPEN SOURCE: VENDOR DOMINATED
Dominated by a single vendor
OPEN SOURCE: VENDOR DOMINATED
Vendor may control committs
OPEN SOURCE: VENDOR DOMINATED
Juniper: Open Contrail
Big Switch: Floodlight
Oracle: Java
Oracle: MySQL
OPEN SOURCE: Foundation Manged
OPEN SOURCE:Foundation Manged
Product-neutral, vendor-neutral
OPEN SOURCE: Foundation Manged
Normally comprised of many vendors
OPEN SOURCE: FOUNDATION MANGED
Widely considered the "best" type
OPEN SOURCE: FOUNDATION MANGED
Examples: OpenStack, OpenDaylight, Apache
Mechanics of Engaging
Project meetings
PROJECT MEETINGS
PROJECT MEETINGS
Mailing lists
Mailing lists
Best for reaching all devs in a given project
Mailing lists
discuss
integration-dev
netvirt-dev
release
tsc
IRC
IRC
Good for pinging people directly
IRC
Channels (Freenode):
#opendaylight
#opendaylight-integration
#opendaylight-meetings
Best Practices
Upstream First
UPSTREAM FIRST
Develop code upstream
Don't develop internally and then throw over wall
UPSTREAM FIRST
Easier for *everyone*
UPSTREAM FIRST
Get feedback before putting in too much work
UPSTREAM FIRST
Integrating into a moving target is hard
UPSTREAM FIRST
Example: OPNFV subproject fork of ODL AAA
Community's Pulse
COMMUNITY'S PULSE
Follow closely enough to be aware of happenings
Email lists, Gerrits, meetings
COMMUNITY'S PULSE
Almost release time?
Audit for blocking bugs, be responsive to mail, etc
COMMUNITY'S PULSE
Discussing <major topic>?
Follow discussion, give feedback early enough to be effective
COMMUNITY'S PULSE
Be active, not a zombie project that wakes up once a release
Code review
CODE REVIEW
Huge benefits from doing it right
CODE REVIEW
Discussion with experts about proposed change
CODE REVIEW
Valuable feedback
Easier way?
Best practices to follow?
Spot bugs, places that need work
CODE REVIEW
Learning opportunity
No one knows everything
Diverse experts have much to teach
CODE REVIEW
Don't take -1/-2 harshly
Everyone gets them all the time
Even the best changes start with -1/-2
CODE REVIEW
Don't self-merge
You can't see everything, make use of your community
*very few exceptions
CODE REVIEW
Manageable-size changes
Don't develop huge chunks downstream, drop upstream
Very hard to review
How can we help?
HOW CAN WE HELP?
Discuss:
How can we help Chinese contributors engage upstream?
Contact
Daniel Farrell
Twitter, IRC: dfarrell07
WeChat #: +1 919 576 0112
Email: dfarrell@redhat.com
Best practices for Engaging in the Upstream Project
By Daniel Farrell
Best practices for Engaging in the Upstream Project
Talk given at OPNFV Summit in Beijing
