[webkit-dev] WebKit Transition to Git

[Tetsuharu OHZEKI]

I feel from this discussion that everybody has their own best way and
we’re tackling to resolve them at once in this migration process.
I also feel it’s a bit difficult to conclude something.

FWIW, I would like to write some my problems about the current
workflow to help figure out
what is a problem in the current workflow and what we should be
resolved in this or other future process.

This would not propose an actual solution, but I believe this would
help to find a final solution and other people will also say your
problems to help.


1. Code review tools
WebKit Bugzilla’s code review tool is not a beautiful solution for today.
I would like to get a preview for markdown file or syntax highlights.


2. Bug Tracking System
I don’t feel a problem to use WebKit Bugzilla, and I doubt that using
Bugzilla is really a problem to collect a feedback from the webdev
community as other people said in this thread.
However, I have some complaints…

* I’d like to write markdown as a comment for bugs.
* I’d be happy if we triage more bugs. There are a bunch of non-triaged bugs.
    * Of course, a triage is a complex problem for us if we do it more
aggressively because there are at least 2 bug tracking systems,
Bugzilla and Apple’s rader…


3. Changelog
I don’t feel it's a big problem to write ChangeLog file.
Of course, this is tired thing but I don’t have a strong alternative
after reading this thread.

However the current `prepare-Changelog` script does not fit with a
branch -based workflow on Git, I feel. There is a room to polish on
this Git migration.

For example, I’d like to specify a branch as my working set in my
local machine, instead of commit or staged changes.

Ordinary, I do these flows but it’s a bit tired…. (if you know more
good ways, could you tell me!):

1. Run `prepare-Changelog`
2. Format ChangeLog file and remove duplicated entries added by _steps 1_.
3. Fuse new changes into a single patch by  `git add . && git commit
--ammend` or `git commit --fixup HEAD && git rebase master -i
--autosquash`
4. Upload patches by  `webkit-patch upload -g HEAD`

I don’t have an objection that we merge a squashed patch into trunk to
simplify the history but we would have some chance to improve the script.

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