Upstreaming 101
summary
Practical how-to for getting changes into mainline Linux: uses git pull requests and the linux.org merge tree with weekly release candidates published on Sundays, a two‑week merge window and roughly three‑month release cadence; kernel size is ~10 million LOC; run scripts/checkpatch to fix style, sign commits with the Developer Certificate of Origin line, land small incremental patches that always compile and boot so git bisect works, test against linux-next, and split complex features (example: converting the loopback static instance to dynamic pointers to enable multiple instances).
AI-written summary · about
chapters (10)
- 0:00Introduction to upstreaming
- 1:54Why upstream patches matter
- 8:40Linux kernel development cycle
- 16:10Linux kernel code organization
- 26:03Mailing lists and communication
- 28:33Starting with simple contributions
- 34:25Developer Certificate of Origin
- 40:38Sending complex contributions
- 49:00Mindset for successful contributions
- 54:39Q&A on upstreaming across projects
related talks
37mGetting Your Patches in Mainline Linux: What Not To Do (& a Few Things You Could Try
45mFrom an Idea to a Patch in the Linux Mainline
36mNo, It's (Still) Never Too Late to Upstream Your Legacy Linux Based Platforms
39mThe Life of a Kernel Bugfix- 36mNo, It's (Still) Never Too Late to Upstream Your Legacy Linux Based Platforms
35mKeynote: Linus Torvalds, Creator of Linux & Git, in Conversation with Dirk Hohndel
40mKeynote: Linus Torvalds, Creator of Linux & Git, in conversation with Dirk Hohndel, VP
32mHow (Not) to Get the Vendor Driver Merged Upstream