How To Get Your Patch Accepted
summary
Three concrete things decide acceptance: correct, tested, minimal code; clear words explaining what changed and why i care; and alignment with project direction so maintainers can merge. Practical tools mentioned: use git diff ... with three dots and a GUI diff (vimdiff or meld), run CI via commit status API (Travis/Jenkins) to catch syntax/style failures, rebase or merge to ensure it actually merges. Large surprises get rejected — one coding-standards change was 37,000 lines and was too big to review.
AI-written summary · about
chapters (23)
- 0:00Introduction
- 1:33Patch acceptance ingredients
- 2:34Preparing patch before submit
- 6:28Diff tools effectively
- 8:19Small patches accepted more
- 10:48Code mistakes to avoid
- 12:54Test code thoroughly
- 14:40Break code for quality
- 17:05Automated checks & messages
- 21:20Writing helpful and detailed commit messages
- 25:15Merge conflicts check
- 27:25Pull request correctly
- 29:51PR description clear
- 33:02Code review process
- 35:35Skepticism in review
- 37:00Peer review collaboration
- 41:59Reviewers beyond the diff
- 42:19Docs & tests required
- 45:32Handle rejection constructively
- 47:42Feedback balanced & constructive
- 50:46Harsh feedback & imposter syndrome
- 52:09PRs start conversations
- 53:12Question and answer session
related talks
37mGetting Your Patches in Mainline Linux: What Not To Do (& a Few Things You Could Try
33mCode review for Open Source
34mContributing your first patch to the Qt Project
49mMaking your patch more committable
53mUpstreaming 201
57mA Meritocracy of Pull Requests
21mHow To Make AI-Assisted OSS Contributions Review-Ready
36mHow to Get Your Zephyr Patches Merged