Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

Diary of a Drive By Coder
Tips and Tricks for working with Upstream

James Bottomley
jejb@linux.vnet.ibm.com
https://blog.hansenpartnership.com
About Me

 

Container evangelist

Open Source Advocate

  • Converting Business to Open Source

Kernel Developer

  • SCSI Subsystem Maintainer
  • PA-RISC architecture Maintainer
  • Containers
Drive By Coding

 

Android (Cyanogenmod) OpenVPN support

Sipdroid pluggable Codec support

libical timezone fixes

Various evolution fixes

TPM enabling and fixes

What this Talk is not About

Building long term community relations

Becoming a member of a particular community

Instead it's about fixing/enchancing one specific thing in a project

Hence the term Drive By.

How I got into this

Great stereo speaker and conference call speakerphone

But the speakerphone doesn't work in Linux

Actually a pulseaudio problem with HFP vs HSP

I wrote the code to make it work

The Basics of Communities for an Outsider

Our Code vs Your Code

Our Code
 vs 
Your Code

can we maintain it?

are you worthy?

Our Code Communities always most unwelcoming to drive by

But Your Code communities will be suspicious of the maintenance burden

A Problem ignored is a Problem Solved

First Pulseaudio patch set published 1 August 2016

Discussion ensues

So do code changes

but eventually everything fizzles out

except for a mention on the pulseaudio status page

"Being able to use HFP headsets without oFono would be nice, and James Bottomley has submitted patches for that: 1, 2, 3, 4. The patches need still some work, help with finishing them would be appreciated."

Another repost 20 September 2017

This time I've polished up the code and fixed bugs in the original protocol negotiation

Next objection is the ofono people don't like it

After fixing that we get into arguments about how the patch series should be split up

And everything fizzles again.

Result: deadlock

they don't like the code, I don't know why.

Openssl Engine Keys

Problem is actually an API bug

openssl has three separate APIs for loading keys where it should only have one.

Can't be fixed without admitting the API mistake

Finally get the ultimate death knell

"One of our trusted committers has a speculative API which isn't upstream but which you should use."

An invitation to you to complete a feature they haven't written yet to get your code upstream.

An Invitation to Drive By

At Kernel Recipes in Paris Werner Koch (gnupg maintainer) asked me about TPMs

Result was an agreement to code a TPM module for gnupg 2

Showed prototype in-person at FOSDEM this year

Result is a 'tpm-work' branch in the gnupg tree

Note: not upstream yet, but definitely upstream track (assuan)

My Kind of Community

Drive by coding for the kernel, when you're me, is quite easy

I've done a lot of TPM work including a chunk of the in-kernel resource manager

Still, not all plain sailing:

one variable declaration per line

Reverse Christmas tree

Prior reputation helps a lot

But only if the community respects it

So be careful which communities you join

Conclusions
There's a reason community managers want you to join communities
It makes you much more likely to get code upstream
Be prepared for lots of failures if you do drive by coding
In person interaction is still the gold standard for getting patches upstream
Hardest thing can be working out why they don't apply your code and back channels help
Presented using impress.js by Bartek Szopka


Web Developer!
Thank You!
Questions?