Webkit after the Blink fork (April ’13): substantial amount of code was removed (the Chrome-specific stuff); number of contributors and numbers of commits has dropped to about half.
Contributor hierarchy: Contributor can follow bugs and trigger builds/tests – anybody can open an account. Committer can commit patches – s/he needs to have +- 25 reviewed patches landed, have a good judgement and understanding the project policies, good collaboration skills, and support of at least 3 reviewers. The process is kept closed because most contributors work for companies and politics + employer-employee relationship plays a role.. Reviewer/owner is responsible for a specifc subsystem – s/he needs 100+ reviewed patches landed, serious understanding of the source code, have informally reviewed other patches already. In Blink this owner is associated with a directory. Also an additional requirement is to be a Chromium project member already for > 6 months. Blink status can be accelerated if you already have WebKit status. This heavy status requirement makes it very difficult for individual, volunteer contributors to gain status.
In WebKit, everything is tracked in bugzilla. Create a bug, create and upload a patch for it, test it in early warning system (apply-build-test loop for several platforms), review the patch (script automatically finds who is most appropriate to review it; reviewers set a review-OK flag on the patch); commit patch (either manually, or set commit-queue flag that commits it after another final early-warning loop). Some patches don’t require review, e.g. layout tests. Newcomer tip: you need to explicitly ping reviewers to take action on your patch.
Blink works similar to WebKit, but has two separate tools: chromium issues only tracks issues, not patches. Codereview tracks patches. Commit message refers to the issue#. To say it is ready for commit, the reviewer just says “lgtm” (Looks Good To Me). Commit queue bot tries to apply the patch three times because applying may fail due to concurrent changes. Once the patch has landed, the issue is updated automatically.
Compared to contributing to the kernel, the process is quite different. Webkit’s releases match the browsers’. Webkit’s handling of patches is much faster because of the early warning system. According to the speaker, the intent to make a change is announced earlier in WebKit compared to the kernel, which gives more opportunities for community feedback. Formal code review process makes review more trackable. In the kernel, you have to find the maintainers to get acks; in Webkit/Blink, this goes more or less automatically – however, it also happens that you don’t find the right maintainer to ping/CC.
Webkit is almost completely hosted by Apple, but some bots (e.g. Qt bot) are hosted by other companies. Blink is of course mostly hosted by Google.