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.

1. Lessons from Contributng
to WebKit and Blink
Bruno de Oliveira Abinader
WebKit, Chromium/Blink commiter
www.brunoabinader.com
brunoabinader@gmail.com
abinader @ irc.freenode.org

2. 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

3. Contents
➢ Briefng on WebKit and Blink
➢ The WebKit development process
➢ The Blink development process
➢ Comparisons against Linux Kernel development process
➢ Final thoughts
3 / 26

4. 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

5. 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

6. WebKit: Lines of Code
WebKit is open sourced Blink is forked
6 / 26

7. WebKit: Commits / Month
Blink is forked
All time 12 months 30 days
Commits 140887 23635 1545
Contributors 497 303 86
7 / 26

8. WebKit: Actve Contributors
8 / 26
Blink is forked
Top 10 contributors
Apple
Google
Nokia
Research in Motion
Igalia
Intel
Samsung
Univ. Szeged
Adobe
Torchmobile

9. 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

10. 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

11. Blink: Lines of Code
March 2013
(cleanup starts)
April 2013
(Blink is forked)
LOCs gets stabilized: ~2.5 MLOCs
11 / 26

12. Can commit patches
Can follow bugs / trigger try bots
Hierarchical Map
Directory hierarchy
Areas of knowledge
Reviewer
(WebKit)
Owner
(Blink)
Commiter
Contributor*
Status
Amount of people
12 / 26

13. WebKit: Submitng patches
Bugzilla
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

14. 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

15. 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

16. WebKit: Newcomer tps
*For more memes, go to webkitmemes.tumblr.com :-)
16 / 26

17. Blink: Submitng patches
Chromium 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

18. 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

19. Linux Kernel: Development
Process
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

20. Linux Kernel: Process stages
20 / 26
1. Design
2. Early review
3. Wider review
4. Merging into
mainline
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

21. 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

22. 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

23. 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? :-)

24. 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

25. Questons? :-)

26. Thank you.
References:
ohloh.net – charts, statistics
linuxfoundation.org – Linux Kernel development steps
webkit.org | chromium.org/blink – general information
bitergia.com – top contributing companies
Decks available in slideshare.net/brunoabinader
abinader.com.br
brunoabinader@gmail.com
abinader @ irc.freenode.org