Hello WebKit Contributors,

This year, Apple would like to push WebKit’s source code management off of 
Subversion and onto git. Our rationale for this is the rest of the industry has 
settled on git as their source code management solution.  We’re also interested 
in moving to a hosted Git solution (namely, GitHub) to make it easier for new 
contributors to interact with the project. I would like to outline our plan so 
far, and solicit feedback from our contributors about some of the pieces we’re 
still discussing.

Monotonic Commit Identifiers
Of great interest to Apple’s engineers has been retaining some kind of ordered 
tag we can use to refer to commits to make defending CI and bisection easier. 
We’ve developed a scheme for this that assigns commits an ordered identifier 
per-branch, outlined in https://trac.webkit.org/wiki/commit-identifiers 
<https://trac.webkit.org/wiki/commit-identifiers>, designed to be used 
alongside git hashes. These identifiers can be used in our current Subversion 
repository, and we would like to start using them before the project has 
transitions to git.

Hosting the Repository
We're most likely going to be hosting the repository in public GitHub. The 
rationale for choosing GitHub over alternatives (namely, GitLab) is that GitHub 
has a far more active community, and Apple would like WebKit to be more 
connected to the open source community. For this reason, we prefer to place the 
canonical WebKit repository on public GitHub so the project is more accessible 
to new contributors, although some concerns have been raised about GitHub’s 
terms and conditions, which contributors of WebKit would need to agree to in 
addition to the terms and conditions of the WebKit project. We are interested 
in what our current community of contributors thinks about this, and what 
preferences contributors may have.

Patches to Pull Requests
In the coming months, more automation will start using the git version of the 
repository instead of the Subversion version. Even immediately after we switch, 
the patch review workflow will remain what it is now (EWS bots mostly already 
use a git clone as their checkout). We do, however, intend to switch from a 
system of patch review to a system of pull requests. This process will be 
incremental and the patch review system will remain alive as long as Bugzilla 

GitHub Issues
The last part of transitioning away from Subversion is to re-evaluate our bug 
tracker. Bugzilla has served us well, but seems to be an impediment to engaging 
with the open source community. We are interested in moving away from Bugzilla 
and to GitHub Issues, allowing new developers to work with a system they are 
likely already familiar with and to allow us closer integration with 
repositories managed by W3C. Although GitHub Issues has had performance 
problems in the past with projects that have many bugs, these performance 
problems have been resolved to the satisfaction of a few large projects hosted 
on GitHub that are of a comparable scale to WebKit. The biggest blocker we are 
aware of is managing security bugs, since the security advisory system used by 
GitHub is essentially the opposite of how WebKit security bugs work. Moving to 
GitHub Issues, if it happens, will be the last part of this transition, and we 
are interested in soliciting feedback from our contributors on what the WebKit 
project’s integration with GitHub Issues should look like.

Look forward to hearing from all of you,

Jonathan Bedard
WebKit Operations
webkit-dev mailing list

Reply via email to