> On Oct 2, 2020, at 11:47 AM, Tetsuharu OHZEKI <tetsuharu.ohz...@gmail.com> > wrote: > > 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.
We don’t have plans to migrate the wiki in the immediate future, although I suspect that as development workflows switch to GitHub, we will eventually want to move the wiki to GitHub as well. > > > 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 This is something that we’re still figuring out, personal experience like what you’re providing here is super valuable! > > > -- > 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
