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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
