[webkit-dev] WebKit Transition to Git

[Tetsuharu OHZEKI]

I'm not sure about how many people in WebKit watches creating or updating bugs,
but I'd like to mention that because this might be a regression if we
move from bugzilla.

If we move to GitHub Issue, compared to bugzilla, that does not have
"component watching".
(I don't know the case of GitLab's Issue)
We only can watch all issues or not for the repository.

Today's GitHub Issue can move an issue to other repositories but I
don't see much that
some organization hosting a large scale project hosts multiple
repositories which corresponds to a _component_ of bugzilla
and triage an issue by moving on each repository.

Before GitHub implements to move an issue,
as my memory, for example Servo project created a bot to watch some
specific label and
send an email to a subscriber configured by a bot settings to do like
bugzilla's component watching.

I'm not sure about how many people in WebKit watches creating or updating bugs,
but I'd like to mention that because this might be a regression if we
move from bugzilla.


--
Tetsuharu OHZEKI
tetsuharu.ohzeki at gmail.com

On Sat, Oct 3, 2020 at 1:43 AM Jonathan Bedard <jbedard at 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 at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev