Your SlideShare is downloading. ×
Lessons from Contributing to WebKit and Blink
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Lessons from Contributing to WebKit and Blink

6,049
views

Published on

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 …

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.

Published in: Technology

1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total Views
6,049
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
41
Comments
1
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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