Lessons from Contributng to WebKit and Blink
Bruno de Oliveira Abinader WebKit, Chromium/Blink commiter abinader.com.br [email protected] abinader @ irc.freenode.org 2 / 25 Contents
➢ Briefng on WebKit and Blink
➢ The WebKit development process
➢ The Blink development process
➢ Comparisons against Linux Kernel development process
➢ Final thoughts 3 / 25 Briefng on WebKit
➢ Web engine: Used by apps to render web content
➢ Open source: Both BSD and LGPL licenses
➢ Community-oriented: Apple, Google, Intel, Samsung...
➢ Multple targets: Desktop, Mobile, Tablets
➢ Multple ports: Cocoa, Qt, EFL, GTK, OpenGL, Cairo 4 / 25 WebKit: Project Statstcs
➢ Started in 2001 (fork of KHTML)
➢ Open sourced in 2005
➢ 4.8 million LOCs (C++, C, Objectve-C)
➢ ~300 commiters, ~130 reviewers
➢ ~40% of browsers market share (Nov '12)
➢ Afer Blink: ~8.5% (Safari), ~40% (Chrome) (Sep '13) 5 / 25 WebKit: Lines of Code
WebKit is open sourced Blink is forked 6 / 25 WebKit: Commits / Month
All time 12 months 30 days Blink is forked Commits 140887 23635 1545
Contributors 497 303 86 7 / 25 WebKit: Actve Contributors
Top 10 contributors Apple Google Nokia Research in Motion Igalia Intel Samsung Univ. Szeged Adobe Blink is forked Torchmobile 8 / 25 Briefng on Blink
➢ Fork of WebKit as of April 2013
➢ Single port: Chromium
➢ Not standalone: Chromium's content layer implementaton
➢ JavaScript engine: V8 (WebKit uses JavaScriptCore)
➢ Multprocess architecture: Browser + Renderer processes
➢ Difers from WebKit2 API multprocess architecture 9 / 25 Blink: Diferent Goals
➢ Greater freedom in implementng WebCore's features
➢ Experimental features can be enabled on runtme
➢ Avoid vendor prefxes:
➢ No more -{moz,webkit,opera}-
➢ Lighter codebase:
➢ Cleaned inherited build systems, platorm and port-specifc code
➢ Move non-core layout and rendering code to Chromium 10 / 25 Blink: Lines of Code
LOCs gets stabilized: ~2.5 MLOCs
March 2013 April 2013 (cleanup starts) (Blink is forked) 11 / 25 Hierarchical Map
Directory hierarchy Reviewer Owner (WebKit) (Blink) Can commit patches Areas of knowledge Commiter
Can follow bugs / trigger try bots s u t a t
Contributor* S Amount of people 12 / 25 WebKit: Submitng patches
Bugzilla
1. Create / Select a bug 2. Create patch / build / test
3. Upload patch Gardening patch
4. Early warning system
Manual commit 5. Request review fag (R?)
6. Request commit queue fag (CQ?) 7. Patch is landed 13 / 25 WebKit: Becoming a commiter
➢ Have around 25 reviewed patches landed
➢ Good judgement and understanding of project policies
➢ Good collaboraton skills
➢ Nominaton requires support of at least 3 reviewers:
➢ 1 to nominate, 2 to acknowledge
➢ Process happens inside reviewers-only mailing list 14 / 25 WebKit: Becoming a reviewer
➢ Have around 100 reviewed patches landed
➢ Serious understanding of the source code
➢ Had informally reviewed other patches already
➢ Ensure reviewed patches follows project policies
➢ Exceptonal judgement on source code changes 15 / 25 WebKit: Newcomer tps
*For more memes, go to webkitmemes.tumblr.com :-) 16 / 25 Blink: Submitng patches
Chromium issues 1. Create / Select a bug 2. Create patch / build / test
Codereview Bug gets notfed
3. Upload patch
4. Try bots Retries 3x
5. Request review (LGTM?) Manual commit
6. Trigger commit queue bot 7. Patch is landed 17 / 25 Blink: Gaining status ➢ Commiter:
➢ Follows the same criteria as WebKit
➢ Can be speed up if already a WebKit commiter
➢ Owner:
➢ Have provided high quality reviews / design feedback
➢ Be a Chromium project member for at least 6 months
➢ Have submited a substantal number of non-trivial changes
➢ Had commited patches to the afected directory within 90 days
➢ Bandwidth to contribute with other owners 18 / 25 Linux Kernel: Development Process
➢ Vanilla releases made by Linus Torvalds
➢ Stable and Experimental releases also available
➢ New releases every 2-3 months
➢ WebKit / Blink: Version depends on target browser
➢ Patch lifetme: Quick for minor fxes, years for large and/or controversial changes
➢ WebKit / Blink: Faster triaging tmes 19 / 25 Linux Kernel: Process stages
1.1. Design Design Ofen done without involving community
2.2. Early Early review review Patch gets posted to relevant mailing list
3.3. Wider Wider review review Patch gets accepted by a subsystem maintainer
4. Merging into 4. Merging into Merging usually done by Linus Torvalds mainlinemainline
5.5. Release Release Developer should take responsibility for the code 20 / 25 Linux Kernel: Comparisons
➢ Design step:
➢ WebKit and Blink promotes openness on current development
➢ i.e. “Intend to implement/ship” emails on Blink-dev
➢ Early review:
➢ WebKit uses bugzilla, Blink uses Rietveld (codereview)
➢ Good to track history / separate issues in a logical scope
➢ Plus: WebKit's Early Warning System, Blink's try bots 21 / 25 Linux Kernel: Comparisons
➢ Wider review / merging into mainline:
➢ A reviewer/owner acknowledgement usually is enough
➢ In the worst case, patches can be rolled back
➢ Integraton: EWS/Try bots always have HEAD
➢ If the patch fails, developer takes responsibility to rebase / update
➢ Testng on the fy: Layout tests as replacement for unit tests 22 / 25 Linux Kernel: Comparisons
➢ Hierarchy model:
➢ Developer → {driver, sub} maintainer→ subsystem maintainer → Linus Torvalds
➢ Developer → Andrew Morton → Linus Torvalds
➢ If a patch touches 2+ places maintained by 2+ maintainers, “Acked-by” enters in scene
➢ Getng patches inside depends on fnding the right maintainer
➢ Remember WebKit meme on having a bad tme? :-) 23 / 25 Final thoughts
➢ WebKit, Blink and Linux Kernel projects are:
➢ Open source, community-oriented projects
➢ Strict in terms of development processes
➢ Meritocracy-based hierarchy levels
➢ WebKit and Blink awesomeness:
➢ Automatzed patch triage system (including tests)
➢ Bug tracking system / history (web tools) Questons? :-) Thank you.
References: ohloh.net – charts, statstcs linuxfoundaton.org – Linux Kernel development steps webkit.org | chromium.org/blink – general informaton bitergia.com – top contributng companies
Decks available in slideshare.net/brunoabinader abinader.com.br [email protected] abinader @ irc.freenode.org