Trying to Explain the 'Incomprehensible' Decision Making Process of a Subsystem Maintainer
summary
I2C maintainership faces scaling: accepted patches per cycle rise from ~2,000 (v3.0) to ~14,000 (v4.8) while backlog grows exponentially, not chronologically, and tested-by tags stay low (roughly 20% → ~40%). Maintainers rely on patchwork to track state and use checkpatch and simple hooks to catch obvious issues; two co-maintainers were added but that only partly helps. Practical fixes: more company reviewers, users supplying tested-by, authors self-review and run checks, and smaller, well-documented patches get processed sooner.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 1:51Subsystem maintainer burden
- 10:57Backlog explosion
- 17:38Patch prioritization
- 23:56Community and organizational solutions
- 33:36Patch submission expectations
- 36:33Future of maintainers
- 39:00Q&A on device tree bindings
related talks
56mMaintainer_s Diary - We Have a Scaling Problem
28mYou may be a Linux Kernel Maintainer - and Not Know It!
01h 27mMeet the Maintainers: Discuss Roles and Responsibilities, Areas of Improvements and...
38mGuide To Become Linux Kernel Maintainer
14mKeynote: The Maintainer's Paradox
25mLinux: Where Are We Going
32mRebuilding the Cathedral
56mMeet the Maintainers BoF