Re: [webkit-dev] Issue reports, merge requests, etc. (was: WebKit Transition to Git)

[Ryosuke Niwa]

I feel like I should write longer replies but here we go.

On Fri, Oct 2, 2020 at 12:53 PM Michael Catanzaro  wrote:
>
> On Fri, Oct 2, 2020 at 11:51 am, Ryosuke Niwa  wrote:
> > Since Igalia has a lot
> > more experience working with other open source projects, do you have
> > some suggestions in how to approach that?
>
> Sorry for a long-ish mail. I didn't mean for this to turn into an
> essay. Too late. :P
>
> I actually moved to Red Hat, but anyway, I would say first step is to
> ensure every incoming issue is triaged, at least once when initially
> reported, and every merge request given at least cursory review within
> a reasonable amount of time. That's how open source projects attract
> and retain community contributors, and it's been a weakness for WebKit
> for a while (we're not the worst at this, but certainly not good at it
> either). One possible answer for this is to have a "project manager" or
> similar role to triage and prioritize issues, but of course it can also
> be done by developers working together (possibly according to some
> rotation).
>
> WebKit is such a big project that I suspect almost nobody has enough
> expertise to triage all incoming bugs, but most of us have enough
> expertise to figure out which issue labels to apply to an incoming bug
> to pass the issue off to more specialized experts. On GNOME GitLab we
> label incoming issues with Bug, Crash, Enhancement, or Feature (the
> difference between Enhancement and Feature is hazy) and have a variety
> of global and per-project labels that can also be applied to issues
> [1]. The list of current components in WebKit Bugzilla would be a good
> starting point to use here. Every new issue gets reviewed and either
> gets closed or else gets a label applied to indicate it has been
> triaged, usually within one business day. If an issue is open and
> doesn't have any labels, we know it has not been triaged.
>
> A lot of bugs can be closed immediately because they're reported in the
> wrong place, for instance. Most crashes are reported without a
> backtrace; to those, we attach a Needs Information label and point the
> reporter to instructions for getting a backtrace with gdb, and close
> after a few days if not provided. The details don't matter so much as
> the fact that the issue has received minimal human attention. In the
> rare cases where a bug report is perfect and all I need to do is add
> issue labels, I give the issue an upvote to indicate I've seen it, so
> the reporter knows it hasn't been *completely* ignored, even if nobody
> fixes it. The details don't matter so much as that contributors and
> issue reporters feel like they've received at least some attention and
> aren't shouting into a bug wasteland.

Yeah, good bug triaging seems to be a key. A lot of people complain
about how we don't fix bugs they filed as well.

> Then developers subscribe to project-specific labels in accordance with
> their expertise and tolerance for mail. E.g. I watch all issues for
> some projects, but for GLib I'm only subscribed to networking-related
> labels, since problems in the network-related code often impact WebKit.
> Some developers will want to watch only for CSS bugs, only layout bugs,
> only JSC bugs, only WebKitGTK bugs, etc.
>
> Of course, triaging issues doesn't mean they actually get fixed, but
> it's a necessary first step. (And once isn't really enough, either.
> Most of our bugs from 2008 are probably no longer valid, but it takes
> time to review old bugs, and not many people have enough specialized
> technical expertise to triage outside their area of expertise. Anyway,
> once is a starting point.)

Right,  we'd probably continue to receive more bugs than we can chew
on so we'd need some process for prioritization as well.

> Responding to merge requests (or patch reviews) in a timely manner is
> also important (otherwise, contributors disappear). Merge requests take
> longer than issues, but it's good to get to each one within a couple
> days; otherwise, they really start to pile up. We currently have
> patches awaiting review from 2017 [2], and that's just the last time
> somebody decided to mass-deny old review requests. And a lot of these
> are from Apple/Igalia/Sony, who all know who to CC for reviews; imagine
> how much harder it is for someone not familiar with the WebKit
> community to get a patch reviewed. ;) GitHub will probably help with
> this because it puts merge requests front-and-center in its UI, instead
> of requiring us to first discover then take the time to sort through
> the request queue. It's hard to use GitHub without habitually reviewing
> pending requests. ;) The number of open issues and MRs is even clearly
> displayed as a sort of challenge to reduce the number. But we'd need
> some workflow for directing merge requests to appropriate reviewers.
>
> When we move to GitHub, you can expect to start receiving merge
> requests from people who would not take the time and effort to create a
> 

Re: [webkit-dev] WebKit Transition to Git

[Ryosuke Niwa]

On Fri, Oct 2, 2020 at 5:06 PM Michael Catanzaro  wrote:
>
> On Fri, Oct 2, 2020 at 13:48, Ken Russell  wrote:
> > Github's code review UI has a couple of feature gaps in my opinion.
> > It's difficult to look at earlier versions of the pull request, in
> > particular to verify that issues found during code review have been
> > fixed. I remember it also being difficult to figure out whether all
> > comments on earlier versions have been addressed.
>
> I'm not familiar with reviews on GitHub. I just want to add that GitLab
> reviews are great and have none of these problems. It's very easy to
> view older versions of merge requests and compare the differences
> between arbitrary revisions of the merge request. (That's often
> important when reviewing small changes to a large merge request.) Every
> discussion thread is clearly marked as either resolved (green!) or
> unresolved, and you can (and should) configure GitLab to block merges
> until all discussions are resolved. (I would be disappointed if GitHub
> doesn't have the same convenience features, as this helps prevent
> mistakes from being forgotten.)

GitHub totally offers this. See, for example:
https://github.com/whatwg/html/pull/5912

> > I realize that Gerrit might not integrate at all with hosting the
> > repo on Github, but has any thought been given to this aspect of the
> > transition?
>
> That sounds like it would be a significant barrier to contribution, and
> frankly defeat the point of switching. If we have serious concerns with
> GitHub's code review functionality (which, again, I'm not familiar
> with), then we should just use GitLab and have everything in one place.
> (GitLab accepts GitHub logins via OAuth, both on gitlab.com and
> self-hosted instances, so the barrier to contributing remains low
> either way.)

Indeed. Gerrit's UI is also quite dense and hard to use for someone
new to it too:
https://gerrit-review.googlesource.com/c/plugins/replication/+/282176

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Michael Catanzaro]

On Fri, Oct 2, 2020 at 09:43, Jonathan Bedard  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 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.


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


Michael

[1] https://gitlab.com/fsdk-marge-bot


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Michael Catanzaro]

On Fri, Oct 2, 2020 at 13:48, Ken Russell  wrote:
Github's code review UI has a couple of feature gaps in my opinion. 
It's difficult to look at earlier versions of the pull request, in 
particular to verify that issues found during code review have been 
fixed. I remember it also being difficult to figure out whether all 
comments on earlier versions have been addressed.


I'm not familiar with reviews on GitHub. I just want to add that GitLab 
reviews are great and have none of these problems. It's very easy to 
view older versions of merge requests and compare the differences 
between arbitrary revisions of the merge request. (That's often 
important when reviewing small changes to a large merge request.) Every 
discussion thread is clearly marked as either resolved (green!) or 
unresolved, and you can (and should) configure GitLab to block merges 
until all discussions are resolved. (I would be disappointed if GitHub 
doesn't have the same convenience features, as this helps prevent 
mistakes from being forgotten.)


I realize that Gerrit might not integrate at all with hosting the 
repo on Github, but has any thought been given to this aspect of the 
transition?


That sounds like it would be a significant barrier to contribution, and 
frankly defeat the point of switching. If we have serious concerns with 
GitHub's code review functionality (which, again, I'm not familiar 
with), then we should just use GitLab and have everything in one place. 
(GitLab accepts GitHub logins via OAuth, both on gitlab.com and 
self-hosted instances, so the barrier to contributing remains low 
either way.)


Michael


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Jonathan Bedard]

> On Oct 2, 2020, at 11:47 AM, Tetsuharu OHZEKI  
> wrote:
> 
> Hi Jonathan,
> 
> As a contributor, I hear this change positively and I'm looking
> forward to transition to a new process.
> 
> I have some questions and feelings:
> 
> 1. Will we continue to use https://trac.webkit.org/wiki after moving
> to something to host the Git repository?
> 
> This is just my curiosity.

We don’t have plans to migrate the wiki in the immediate future, although I 
suspect that as development workflows switch to GitHub, we will eventually want 
to move the wiki to GitHub as well.

> 
> 
> 2. About GitHub Issues, how will we categorize an issue?
> 
> I feel GitHub issues require some techniques to manage/categorize a bug
> when we host a large scale project like a Web Engine on GitHub issues.
> I think it might be a bit harder than doing with Bugzilla.
> 
> As my past experiences to collaborate with some projects,
> Rust and Servo project's label management was nice to categorize issues.
> https://github.com/rust-lang/rust-wiki-backup/blob/master/Note-tag-label-names-and-definitions.md

This is something that we’re still figuring out, personal experience like what 
you’re providing here is super valuable!

> 
> 
> --
> Tetsuharu OHZEKI
> tetsuharu.ohz...@gmail.com
> 
> 
> 
> 
> On Sat, Oct 3, 2020 at 1:43 AM Jonathan Bedard  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-dev] Issue reports, merge requests, etc. (was: WebKit Transition to Git)

[Michael Catanzaro]

On Fri, Oct 2, 2020 at 11:51 am, Ryosuke Niwa  wrote:

Since Igalia has a lot
more experience working with other open source projects, do you have
some suggestions in how to approach that?


Sorry for a long-ish mail. I didn't mean for this to turn into an 
essay. Too late. :P


I actually moved to Red Hat, but anyway, I would say first step is to 
ensure every incoming issue is triaged, at least once when initially 
reported, and every merge request given at least cursory review within 
a reasonable amount of time. That's how open source projects attract 
and retain community contributors, and it's been a weakness for WebKit 
for a while (we're not the worst at this, but certainly not good at it 
either). One possible answer for this is to have a "project manager" or 
similar role to triage and prioritize issues, but of course it can also 
be done by developers working together (possibly according to some 
rotation).


WebKit is such a big project that I suspect almost nobody has enough 
expertise to triage all incoming bugs, but most of us have enough 
expertise to figure out which issue labels to apply to an incoming bug 
to pass the issue off to more specialized experts. On GNOME GitLab we 
label incoming issues with Bug, Crash, Enhancement, or Feature (the 
difference between Enhancement and Feature is hazy) and have a variety 
of global and per-project labels that can also be applied to issues 
[1]. The list of current components in WebKit Bugzilla would be a good 
starting point to use here. Every new issue gets reviewed and either 
gets closed or else gets a label applied to indicate it has been 
triaged, usually within one business day. If an issue is open and 
doesn't have any labels, we know it has not been triaged.


A lot of bugs can be closed immediately because they're reported in the 
wrong place, for instance. Most crashes are reported without a 
backtrace; to those, we attach a Needs Information label and point the 
reporter to instructions for getting a backtrace with gdb, and close 
after a few days if not provided. The details don't matter so much as 
the fact that the issue has received minimal human attention. In the 
rare cases where a bug report is perfect and all I need to do is add 
issue labels, I give the issue an upvote to indicate I've seen it, so 
the reporter knows it hasn't been *completely* ignored, even if nobody 
fixes it. The details don't matter so much as that contributors and 
issue reporters feel like they've received at least some attention and 
aren't shouting into a bug wasteland.


Then developers subscribe to project-specific labels in accordance with 
their expertise and tolerance for mail. E.g. I watch all issues for 
some projects, but for GLib I'm only subscribed to networking-related 
labels, since problems in the network-related code often impact WebKit. 
Some developers will want to watch only for CSS bugs, only layout bugs, 
only JSC bugs, only WebKitGTK bugs, etc.


Of course, triaging issues doesn't mean they actually get fixed, but 
it's a necessary first step. (And once isn't really enough, either. 
Most of our bugs from 2008 are probably no longer valid, but it takes 
time to review old bugs, and not many people have enough specialized 
technical expertise to triage outside their area of expertise. Anyway, 
once is a starting point.)


Responding to merge requests (or patch reviews) in a timely manner is 
also important (otherwise, contributors disappear). Merge requests take 
longer than issues, but it's good to get to each one within a couple 
days; otherwise, they really start to pile up. We currently have 
patches awaiting review from 2017 [2], and that's just the last time 
somebody decided to mass-deny old review requests. And a lot of these 
are from Apple/Igalia/Sony, who all know who to CC for reviews; imagine 
how much harder it is for someone not familiar with the WebKit 
community to get a patch reviewed. ;) GitHub will probably help with 
this because it puts merge requests front-and-center in its UI, instead 
of requiring us to first discover then take the time to sort through 
the request queue. It's hard to use GitHub without habitually reviewing 
pending requests. ;) The number of open issues and MRs is even clearly 
displayed as a sort of challenge to reduce the number. But we'd need 
some workflow for directing merge requests to appropriate reviewers.


When we move to GitHub, you can expect to start receiving merge 
requests from people who would not take the time and effort to create a 
WebKit Bugzilla account and learn how to use our arcane ChangeLog and 
patch creation scripts. Epiphany has twice as many active contributors 
and probably 3-4x more activity today on GNOME GitLab than it did when 
we used GNOME Bugzilla, and I'm pretty sure that's mainly due to GitLab 
rather than other factors. I wouldn't expect that dramatic a change for 
WebKit, since most WebKit contributors are professional rather than 
volunteer 

Re: [webkit-dev] WebKit Transition to Git

[Ryosuke Niwa]

On Fri, Oct 2, 2020 at 11:00 AM Michael Catanzaro  wrote:
>
> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand 
> wrote:
> > Would you also consider preventing merge commits in order to keep a
> > clean mainline branch?
>
> Big +1 to blocking merge commits. Merge commits in a huge project like
> WebKit would make commit archaeology very frustrating. (I assume this
> is implied by the monotonic commit identifiers proposal, but it doesn't
> exactly say that.)
>
> I'm sure transition to git and GitHub should go well. I would have
> selected GitLab myself -- it's nicer and also overwhelmingly popular --
> but whatever. (Does GitHub have merge request approvals? Replicating
> our reviewer/owner permissions with GitLab merge request approvals
> would be easy.)
>
> One downside is that using github.com might actually make it *too* easy
> to spam us with low-quality issue reports and merge requests. We've
> historically been pretty bad at maintaining a clean issue tracker --
> the quantity of untriaged issues on Bugzilla is very high -- and GitHub
> will make this worse. That's not an issue with the GitHub platform,
> though. Just something to stay on top of.

Since one of the goals is to engage better with the web developer
community, it's imperative that we improve this process. e.g. we need
some way to review & triage newly filed issues. Since Igalia has a lot
more experience working with other open source projects, do you have
some suggestions in how to approach that?

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Tetsuharu OHZEKI]

Hi Jonathan,

As a contributor, I hear this change positively and I'm looking
forward to transition to a new process.

I have some questions and feelings:

1. Will we continue to use https://trac.webkit.org/wiki after moving
to something to host the Git repository?

This is just my curiosity.


2. About GitHub Issues, how will we categorize an issue?

I feel GitHub issues require some techniques to manage/categorize a bug
when we host a large scale project like a Web Engine on GitHub issues.
I think it might be a bit harder than doing with Bugzilla.

As my past experiences to collaborate with some projects,
Rust and Servo project's label management was nice to categorize issues.
https://github.com/rust-lang/rust-wiki-backup/blob/master/Note-tag-label-names-and-definitions.md


--
Tetsuharu OHZEKI
tetsuharu.ohz...@gmail.com




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

Re: [webkit-dev] WebKit Transition to Git

[Michael Catanzaro]

On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand  
wrote:

Would you also consider preventing merge commits in order to keep a
clean mainline branch?


Big +1 to blocking merge commits. Merge commits in a huge project like 
WebKit would make commit archaeology very frustrating. (I assume this 
is implied by the monotonic commit identifiers proposal, but it doesn't 
exactly say that.)


I'm sure transition to git and GitHub should go well. I would have 
selected GitLab myself -- it's nicer and also overwhelmingly popular -- 
but whatever. (Does GitHub have merge request approvals? Replicating 
our reviewer/owner permissions with GitLab merge request approvals 
would be easy.)


One downside is that using github.com might actually make it *too* easy 
to spam us with low-quality issue reports and merge requests. We've 
historically been pretty bad at maintaining a clean issue tracker -- 
the quantity of untriaged issues on Bugzilla is very high -- and GitHub 
will make this worse. That's not an issue with the GitHub platform, 
though. Just something to stay on top of.


Michael


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Philippe Normand]

This is great!

On Fri, 2020-10-02 at 09:43 -0700, Jonathan Bedard 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.
> 

Have you seen how this was handled in LLVM?
https://releases.llvm.org/9.0.0/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git

Would you also consider preventing merge commits in order to keep a
clean mainline branch?

Philippe

> 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

[webkit-dev] WebKit Transition to Git

[Jonathan Bedard]

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