[webkit-dev] WebKit Transition to Git

[Jonathan Bedard]

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20201002/1cbfe18b/attachment.htm>