3. Contributing to Docker
introduction
obligatory stats
IT’S OVER NINE-THOUSAND!
j Git/GitHub Stats
j Over 12,000 stars (yeah, we passed 9,000 a while ago... indulge me? :))
j Over 2,000 forks
j Over 450 contributors
j File Types
j Over 590 Go files (and over 160 of those are _test.go files)
j Over 160 Markdown files
j Over 60 Bash/Shell files
j Even 15+ CSS and 20+ JavaScript files!
j IRC
j Averaging 900+ in #docker
j ... and 150+ in #docker-dev
4. Contributing to Docker
clearly, many ways to contribute
helping out!
No Code, No Code
j Support in #docker on IRC and on the “docker” ML
j Triaging issues (reproducing, chasing down duplicates)
j Constructive dialog on issues, pull requests, and the
“docker-dev” ML
j Bug hunting and filing new issues
5. Contributing to Docker
clearly, many ways to contribute
packaging
Insert Your Favorite Distribution Here
j Alpine
j Arch
j boot2docker
j CentOS
j CoreOS
j CRUX
j Debian
j Fedora
j FrugalWare
j Gentoo
j Homebrew
j Nix
j openSUSE
j RHEL
j Slackware
j Ubuntu
j If you’re interested in helping make this list even longer,
read hack/PACKAGERS.md and get in touch with me!
6. Contributing to Docker
clearly, many ways to contribute
reviewing PRs
“IANTM” — I Am Not The Maintainer
j Be kind and respectful, especially of contributor’s time
(donated time is a precious resource we shouldn’t waste)
7. Contributing to Docker
clearly, many ways to contribute
reviewing PRs
Become A Maintainer!
j (see CONTRIBUTING.md and hack/MAINTAINERS.md)
j Learn the component you want to maintain inside and out
j Check out Gordon
(https://github.com/dotcloud/gordon)
j Contribute code, bugfixes, support, etc.
j Propose yourself at the weekly contributors meeting in
#docker-dev (Thursdays at 10:30am PST)
j Submit a PR adding yourself to the MAINTAINERS file for
the component
8. Contributing to Docker
pull requests!
are you sure??
So, you really want to submit a PR?
j Bug Fixes
j Feature Enhancements
j Documentation
j (remember those nice file type stats we saw earlier?
there’s something for everyone here!)
9. Contributing to Docker
pull requests!
respect!
Maintainers Are Contributors Too
j As stressed earlier, be respectful of time — we all only have
so much of it!
j If it’s a large change, discuss it somewhere first so your
own time isn’t wasted (on IRC in #docker-dev, on the
“docker-dev” ML, etc)
10. Contributing to Docker
pull requests!
building blocks
Git / GitHub
j git clone https://github.com/dotcloud/docker.git
j git remote add yourname git@github.com:yourname/docker.git
j git fetch --all -p
j (master always tracks origin/master)
j git checkout -b your-new-pr-branch
j Once you’ve submitted your PR with a branch, keep it; force push it to
update your PR (in GitHub, one PR = one branch)
11. Contributing to Docker
pull requests!
building blocks
Unit Tests, Integration Tests, and CLI Integration
Tests, Oh My!
j Simple - if your functions can be tested easily, create a
Go-standard yourfilename_test.go file and throw your
tests inside it.
j Complex - if, on the other hand, your tests require more of
Docker available (or you want to test complex features or
feature interactions),
integration-cli/docker_cli_commandtotest_test.go.
j integration/ is our old integration tests - if you want
some likely-easy PRs, help us convert them over to
integration-cli/. :)
12. Contributing to Docker
pull requests!
building blocks
Size Matters
j Small PRs are easy to review (remember that maintainers are
contributors too - time is our precious resource)
j Large PRs are sometimes necessary, but they rob us
(WE REQUIRE MORE VESPENE GAS)
13. Contributing to Docker
pull requests!
building blocks
Building On The Shoulders Of Giants
j I know this really cool project that helps create consistent
userspace environments which are absolutely ideal for
building software... :)
j make, make all
j make shell
j ./hack/make.sh binary
j ./hack/make.sh test
j ./hack/make.sh binary test-integration-cli
14. Contributing to Docker
pull requests!
review
We Don’t Bite!
j Seriously, we try to be pretty nice.
j ... but on the other hand, please try to realize that it’s just
code (trust me, I know this is hard — we can’t all be as
altruistic as crosbymichael).
j Also realize that the person who’s reviewing your code is
probably going to be the sap who has to maintain and
support it, so they’ve got a vested interest in making sure
it’s something they can commit to maintain. If it’s not up
to snuff, they won’t commit, you won’t get merged, and all
that “code snobbery” will have been for naught.
j ./hack/getmaintainer.sh
15. Contributing to Docker
pull requests!
review
Gordon!
j Seriously, did you check him out yet?
j https://github.com/dotcloud/gordon
j If you even have an inkling of becoming a maintainer, he’s
going to help make your life easier.
