Lessons from Contributing to WebKit and Blink
summary
WebKit and Blink use automated bots and strict workflow: patches upload to Bugzilla or Rietveld then run on early warning system bots and trybots/triage bots before reviewer approval; successful commits land via commit-queue/commit-kiwi. Blink shrinks WebKit’s codebase to about 2.5 million lines of code after cleanup, targets Chromium only, and exposes experimental flags at runtime; contributor counts fall from hundreds to under a hundred active after the fork, but monthly commits still top ~1,500.
AI-written summary · about
chapters (11)
- 0:00Start
- 4:20Briefing on Blink
- 8:50Blink: Different Goals
- 12:07Blink: Lines of Code
- 12:37Hierarchical Map
- 15:10WebKit: Submitting patches
- 27:43Blink: Submitting patches
- 36:49Linux Kernel: Process stages
- 41:06Linux kernel: Comparisons
- 43:42Final thoughts
- 44:56Questions? :-
related talks
01h 13mCommitters Panel
22mKeynote: A Fireside Chat with Greg Kroah-Hartman, Linux Foundation Fellow
41mWebKit Rendering: Overview for HTML5 Developers
42mAdvancing WebDriver BiDi support in WebKit
56mMaintainer_s Diary - We Have a Scaling Problem
43mWhy Opera Needs WebKit, or Opium for the People
27mAttacking the WebAssembly Compiler of WebKit
43mUnlocking the Full Potential of WPE To Build a Successful Embedded Product