Making your patch more committable
summary
Shows why a 260k one‑commit patch stalls and how to fix it: break the work into independently useful subprojects, split into small commits that make each commit build and pass tests, keep refactors separate from functional changes, and write commit messages that explain the actual risk and benefit. Give a two‑line reproducible usage, include inline pgbench or timings, report relevant metrics like P99 or memory, and provide minimal reproducible benchmark (pgbench) plus preconditions. Use cscope or apply the patch locally to inspect cross‑file effects and respond to every review item so reviewers know what changed.
AI-written summary · about
chapters (5)
- 0:00Introduction to committable patches
- 3:20Communication and collaboration on mailing list
- 12:05Exercising your code with tests and benchmarks
- 25:54Splitting large commits into smaller ones
- 37:32Closing remarks and Q&A
related talks
37mGetting Your Patches in Mainline Linux: What Not To Do (& a Few Things You Could Try
58mHow To Get Your Patch Accepted
34mContributing your first patch to the Qt Project
50mHacking on Postgres: An Overview
53mUpstreaming 201
47mHow To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here
33mCode review for Open Source
56mMaintainer_s Diary - We Have a Scaling Problem