lessons from contributing to webkit and blink
DESCRIPTION
Being one of the most successful open source projects to date, WebKit development process consists of a series of protocols and strict policies in order to obtain committer and reviewer status. Blink follows a similar approach with committers and scoped code owners, in a similar fashion as Linux Kernel does with its subsystem maintainers. Their open source success is due to not only solid support from major technology companies, but also to the high quality and automated testing performed on patches before submission. In this presentation, Bruno explains how the development process of both WebKit and Blink projects are - from submitting well-tested patches with strict policies to check, get review from community, and commit upstream via commit-queue system (including early warning system bots). This is a very practical talk with live demonstrations of patch submissions on both projects.TRANSCRIPT
Lessons from Contributng to WebKit and Blink
Bruno de Oliveira AbinaderWebKit, Chromium/Blink commiter
[email protected] @ irc.freenode.org
Abstract
What: Comparisons between WebKit & Blink
(Chromium) against Linux Kernel development process
models.
Why: Establish common problems/botlenecks and
share best practces between projects.
2 / 26
Contents
➢ Briefng on WebKit and Blink
➢ The WebKit development process
➢ The Blink development process
➢ Comparisons against Linux Kernel development process
➢ Final thoughts
3 / 26
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 / 26
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 / 26
WebKit: Lines of Code
WebKit is open sourced Blink is forked
6 / 26
WebKit: Commits / Month
Blink is forked
All time 12 months 30 days
Commits 140887 23635 1545
Contributors 497 303 86
7 / 26
WebKit: Actve Contributors
8 / 26
Blink is forked
Top 10 contributors
Apple
Nokia
Research in Motion
Igalia
Intel
Samsung
Univ. Szeged
Adobe
Torchmobile
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 / 26
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}-<property> polyflls!
➢ Lighter codebase:
➢ Cleaned inherited build systems, platorm and port-specifc code
➢ Move non-core layout and rendering code to Chromium
10 / 26
Blink: Lines of Code
March 2013(cleanup starts)
April 2013(Blink is forked)
LOCs gets stabilized: ~2.5 MLOCs
11 / 26
Can commit patches
Can follow bugs / trigger try bots
Hierarchical MapDirectory hierarchy
Areas of knowledge
Reviewer(WebKit)
Owner(Blink)
Commiter
Contributor* Stat
us
Amount of people
12 / 26
WebKit: Submitng patchesBugzilla
1. Create / Select a bug 2. Create patch / build / test
3. Upload patch
4. Early warning system
5. Request review fag (R?)
6. Request commit queue fag (CQ?) 7. Patch is landed
Gardening patch
Manual commit
13 / 26
WebKit: Becoming a commiter➢ Have around 25 reviewed patches landed
➢ Good judgment 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 / 26
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 judgment on source code changes
15 / 26
WebKit: Newcomer tps
*For more memes, go to webkitmemes.tumblr.com :-)
16 / 26
Blink: Submitng patchesChromium issues
1. Create / Select a bug 2. Create patch / build / test
3. Upload patch
4. Try bots
5. Request review (LGTM?)
6. Trigger commit queue bot 7. Patch is landed
Codereview
Retries 3x
Manual commit
Bug gets notfed
17 / 26
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 / 26
Linux Kernel: DevelopmentProcess
19 / 26
➢ 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
Linux Kernel: Process stages
20 / 26
1. Design
2. Early review
3. Wider review
4. Merging intomainline
5. Release
Ofen done without involving community
Patch gets posted to relevant mailing list
Patch gets accepted by a subsystem maintainer
Merging usually done by Linus Torvalds
Developer should take responsibility for the code
Linux Kernel: Comparisons
21 / 26
➢ 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
Linux Kernel: Comparisons
22 / 26
➢ 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
Linux Kernel: Comparisons
23 / 26
➢ 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? :-)
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)
24 / 26
Questons? :-)
Thank you.References:ohloh.net – charts, statisticslinuxfoundation.org – Linux Kernel development stepswebkit.org | chromium.org/blink – general informationbitergia.com – top contributing companies
Decks available in slideshare.net/brunoabinader
[email protected] @ irc.freenode.org