[webkit-dev] WebKit Transition to Git
Jonathan Bedard
jbedard at apple.com
Mon Oct 5 08:40:02 PDT 2020
> On Oct 2, 2020, at 5:05 PM, Michael Catanzaro <mcatanzaro at gnome.org> wrote:
>
> On Fri, Oct 2, 2020 at 09:43, Jonathan Bedard <jbedard at apple.com> wrote:
>> 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.
>
> I don't think we need much integration to use the issue tracker? Once we migrate existing bugs from WebKit Bugzilla, we can use it as we would any other issue tracker? Why would it require integration?
We have some tooling attached to bugzilla (webkit-patch is the highest profile, but there are a few others), that’s the sort of thing I’m referring to.
>
> We might need to use a separate repository with more limited permissions to handle security reports. At least in GitLab, all project developers (committers) have access to all confidential issues. I'm not sure about GitHub, but I assume it would be the same.
That's one solution, but even that is somewhat insufficient because we don’t want to give someone access to every security issue just to give access to a single one. One of the solutions we’ve discussed is to migrate bugs component by component, the security component may stay on bugzilla indefinitely.
>
> What will require integration is pull request merges. If we want to maintain linear version history, we will want a merge bot. On GNOME GitLab, we have a large number of smaller projects and it's we don't need them, but for a one huge project like WebKit there will be too many conflicts otherwise, because every commit going into the main branch will require all other pull requests to be rebased. A merge bot -- e.g. [1] -- will handle that for us. (Not sure what merge bots are common on GitHub. )
We definitely will have a merge bot (basically what the current commit queue is). They are pretty common in GitHub, especially because they’re a good way to manage access to protected branches. Aakash and I have discussed some of the specifics, the #github-migration channel on Slack is going to be the best place to discuss the details of this.
>
> Michael
>
> [1] https://gitlab.com/fsdk-marge-bot
>
>
More information about the webkit-dev
mailing list