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