Committer Review: An Exercise in Paranoia
summary
Explains why committers act cautiously: committing creates open‑ended responsibility for breakage and long‑term maintenance, so reviewers follow a hierarchy — understandability → desirability → architecture → detailed checks — and use concrete tools and tactics like git grep, checking for paired alloc/free, pgindent style, HeapTuple/Datum macros and SearchSysCache variants. Gives hard numbers and examples: a one‑line omission caused data corruption, pg_overexplain required six followup commits after breaking the build farm, and roughly 20% post‑commit fixups in February.
AI-written summary · about
chapters (11)
- 0:00Introduction to talk
- 1:00What is committer mindset
- 13:41Reviewing patches overview
- 14:45Start with big picture
- 15:06Consistency is critical
- 15:27Be a pessimist reviewer
- 16:09Spirit of maintainership
- 25:34Reviewing for consistency
- 35:49Why pessimism matters
- 42:56Spirit of maintainership deep dive
- 45:06Q&A session
related talks
29mCode review, do you speak it?
59mCode Reviews - Why, what and how
56mThe art of keeping your project from falling apart
43mCode Review, you said?
46mLooks GREAT To Me: Getting Past Bare Minimum Code Reviews
01h 01mCode Reviews: building better code and stronger teams
38mCracking the Code Review: from Guesswork to Automated Guidance
48mEffective Code Reviews