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?

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

Meetings wiki

PROJECT MEETINGS

Meetings GCal

Mailing lists

Best for reaching all devs in a given project

Mailing lists

discuss

integration-dev

netvirt-dev

release

tsc

Full list

IRC

Good for pinging people directly

IRC

Channels (Freenode):

#opendaylight

#opendaylight-integration

#opendaylight-meetings

Full list

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