[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webkit-dev
Subject:    Re: [webkit-dev] WebKit Transition to Git
From:       Tetsuharu OHZEKI <tetsuharu.ohzeki () gmail ! com>
Date:       2020-10-14 13:48:00
Message-ID: CAAY5diDq4GVUXRpgdgfhJgXhHiB58ZruVK1tkr54ysXZ7msTyg () mail ! gmail ! com
[Download RAW message or body]

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@gmail.com


On Sat, Oct 3, 2020 at 1:43 AM Jonathan Bedard <jbedard@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


[prev in list] [next in list] [prev in thread] [next in thread]