This is great!

On Fri, 2020-10-02 at 09:43 -0700, Jonathan Bedard wrote:
> 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 
>, 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.

Have you seen how this was handled in LLVM?

Would you also consider preventing merge commits in order to keep a
clean mainline branch?


> 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 mailing list

Reply via email to