Hi Jonathan, As a contributor, I hear this change positively and I'm looking forward to transition to a new process.
I have some questions and feelings: 1. Will we continue to use https://trac.webkit.org/wiki after moving to something to host the Git repository? This is just my curiosity. 2. About GitHub Issues, how will we categorize an issue? I feel GitHub issues require some techniques to manage/categorize a bug when we host a large scale project like a Web Engine on GitHub issues. I think it might be a bit harder than doing with Bugzilla. As my past experiences to collaborate with some projects, Rust and Servo project's label management was nice to categorize issues. https://github.com/rust-lang/rust-wiki-backup/blob/master/Note-tag-label-names-and-definitions.md -- Tetsuharu OHZEKI tetsuharu.ohz...@gmail.com On Sat, Oct 3, 2020 at 1:43 AM Jonathan Bedard <jbed...@apple.com> 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 > 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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
