Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pull] main from electron:main #3

Open
wants to merge 3,341 commits into
base: main
Choose a base branch
from
Open

[pull] main from electron:main #3

wants to merge 3,341 commits into from

Conversation

pull[bot]
Copy link

@pull pull bot commented Aug 25, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

@commit-lint
Copy link

commit-lint bot commented Aug 25, 2021

Features

Continuous Integration

Code Refactoring

Chore

Tests

Bug Fixes

Documentation

Contributors

codebytere, dsanders11, ckerr, aiddya, tr2-harada, miniak, zcbenz, brhenrique, erickzhao, wanted002, jkleinsc

Commit-Lint commands

You can trigger Commit-Lint actions by commenting on this PR:

  • @Commit-Lint merge patch will merge dependabot PR on "patch" versions (X.X.Y - Y change)
  • @Commit-Lint merge minor will merge dependabot PR on "minor" versions (X.Y.Y - Y change)
  • @Commit-Lint merge major will merge dependabot PR on "major" versions (Y.Y.Y - Y change)
  • @Commit-Lint merge disable will desactivate merge dependabot PR
  • @Commit-Lint review will approve dependabot PR
  • @Commit-Lint stop review will stop approve dependabot PR

@mergify
Copy link

mergify bot commented Apr 15, 2022

@pull-request-quantifier[bot] is not allowed to run commands

This PR has 137834 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80898 -56936
Percentile : 100%

Total files changed: 2249

Change summary by file extension:
.gitignore : +10 -4
.yml : +3505 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13186 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

2 similar comments

This PR has 137834 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80898 -56936
Percentile : 100%

Total files changed: 2249

Change summary by file extension:
.gitignore : +10 -4
.yml : +3505 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13186 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137834 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80898 -56936
Percentile : 100%

Total files changed: 2249

Change summary by file extension:
.gitignore : +10 -4
.yml : +3505 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13186 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137861 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80925 -56936
Percentile : 100%

Total files changed: 2249

Change summary by file extension:
.gitignore : +10 -4
.yml : +3505 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

8 similar comments

This PR has 137861 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80925 -56936
Percentile : 100%

Total files changed: 2249

Change summary by file extension:
.gitignore : +10 -4
.yml : +3505 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137861 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80925 -56936
Percentile : 100%

Total files changed: 2249

Change summary by file extension:
.gitignore : +10 -4
.yml : +3505 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137861 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80925 -56936
Percentile : 100%

Total files changed: 2249

Change summary by file extension:
.gitignore : +10 -4
.yml : +3505 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137861 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80925 -56936
Percentile : 100%

Total files changed: 2249

Change summary by file extension:
.gitignore : +10 -4
.yml : +3505 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137861 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80925 -56936
Percentile : 100%

Total files changed: 2249

Change summary by file extension:
.gitignore : +10 -4
.yml : +3505 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137861 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80925 -56936
Percentile : 100%

Total files changed: 2249

Change summary by file extension:
.gitignore : +10 -4
.yml : +3505 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137861 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80925 -56936
Percentile : 100%

Total files changed: 2249

Change summary by file extension:
.gitignore : +10 -4
.yml : +3505 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137861 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80925 -56936
Percentile : 100%

Total files changed: 2249

Change summary by file extension:
.gitignore : +10 -4
.yml : +3505 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137868 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80932 -56936
Percentile : 100%

Total files changed: 2250

Change summary by file extension:
.gitignore : +10 -4
.yml : +3512 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

11 similar comments

This PR has 137868 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80932 -56936
Percentile : 100%

Total files changed: 2250

Change summary by file extension:
.gitignore : +10 -4
.yml : +3512 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137868 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80932 -56936
Percentile : 100%

Total files changed: 2250

Change summary by file extension:
.gitignore : +10 -4
.yml : +3512 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137868 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80932 -56936
Percentile : 100%

Total files changed: 2250

Change summary by file extension:
.gitignore : +10 -4
.yml : +3512 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137868 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80932 -56936
Percentile : 100%

Total files changed: 2250

Change summary by file extension:
.gitignore : +10 -4
.yml : +3512 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137868 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80932 -56936
Percentile : 100%

Total files changed: 2250

Change summary by file extension:
.gitignore : +10 -4
.yml : +3512 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137868 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80932 -56936
Percentile : 100%

Total files changed: 2250

Change summary by file extension:
.gitignore : +10 -4
.yml : +3512 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137868 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80932 -56936
Percentile : 100%

Total files changed: 2250

Change summary by file extension:
.gitignore : +10 -4
.yml : +3512 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137868 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80932 -56936
Percentile : 100%

Total files changed: 2250

Change summary by file extension:
.gitignore : +10 -4
.yml : +3512 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137868 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80932 -56936
Percentile : 100%

Total files changed: 2250

Change summary by file extension:
.gitignore : +10 -4
.yml : +3512 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137868 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80932 -56936
Percentile : 100%

Total files changed: 2250

Change summary by file extension:
.gitignore : +10 -4
.yml : +3512 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

This PR has 137868 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +80932 -56936
Percentile : 100%

Total files changed: 2250

Change summary by file extension:
.gitignore : +10 -4
.yml : +3512 -2860
.js : +2889 -5054
.json : +1688 -466
.lock : +0 -0
.sh : +20 -8
.clang-tidy : +4 -0
.md : +10372 -5319
.git-blame-ignore-revs : +5 -0
.gitattributes : +20 -4
.nvmrc : +1 -1
.gn : +626 -402
.gni : +1333 -411
.py : +415 -446
.json5 : +5 -1
.tmpl : +60 -0
.h : +6098 -4371
.cc : +15909 -11979
.ts : +20742 -14930
.html : +1478 -1401
.css : +2 -0
.svg : +0 -97
.grd : +0 -6
.grdp : +0 -123
.patches : +113 -64
.patch : +13213 -6720
.bat : +15 -25
.ps1 : +0 -8
.manifest : +43 -26
.mm : +2089 -1797
.plist : +26 -1
.rc : +0 -59
.sigs : +10 -0
.fragment : +2 -0
.mojom : +25 -13
.idl : +92 -2
.eslintrc : +0 -30
.cpp : +9 -6
.txt : +1 -274
.mjs : +48 -0
.gyp : +32 -0
.github/CODEOWNERS : +3 -2
DEPS : +20 -23
ELECTRON_VERSION : +0 -1
script/git-export-patches : +1 -1
script/git-import-patches : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

ckerr and others added 30 commits December 3, 2024 16:25
fix: use '= default' to define a trivial destructor [modernize-use-equals-default]
* Add bare-bones GetSharedDictionaryUsageInfo

* Add GetSharedDictionaryInfo()

* Improve API, use isolation keys

* Add documentation

* Update docs/api/session.md

Co-authored-by: John Kleinschmidt <[email protected]>

* Update shell/browser/api/electron_api_session.cc

Co-authored-by: Samuel Attard <[email protected]>

* Add tests

* Implement feedback <3

* Improve tests

* chore: lint

* docs: add note about clearing cache in ses.clearData

---------

Co-authored-by: John Kleinschmidt <[email protected]>
Co-authored-by: Samuel Attard <[email protected]>
Co-authored-by: alice <[email protected]>
fix: context-menu event with BaseWindows
* fix: unused variable warning when the PDF viewer is disabled

* fix: unused function error  when PDF viewer is disabled

error: unused function ParseManifest [-Werror,-Wunused-function]
Bumps [mikefarah/yq](https://github.com/mikefarah/yq) from 4.44.5 to 4.44.6.
- [Release notes](https://github.com/mikefarah/yq/releases)
- [Changelog](https://github.com/mikefarah/yq/blob/master/release_notes.txt)
- [Commits](mikefarah/yq@bc5b54c...4839dbb)

---
updated-dependencies:
- dependency-name: mikefarah/yq
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.27.5 to 3.27.6.
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@f09c1c0...aa57810)

---
updated-dependencies:
- dependency-name: github/codeql-action
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* chore: bump chromium in DEPS to 133.0.6858.0

* chore: bump chromium in DEPS to 133.0.6860.0

* chore: update patches

v8/revert_fastapi_remove_dynamic_overload_resolution.patch had some additions due to https://chromium-review.googlesource.com/c/v8/v8/+/6023139

* 6044060: Reland "Moves shared GN templates into //build/config/apple."
https://chromium-review.googlesource.com/c/chromium/src/+/6044060

* Revert "6023139: [fastapi] Add support for attribute setters"
https://chromium-review.googlesource.com/c/v8/v8/+/6023139

* Update printing.patch

The removed include is present in the original source file now, just slightly before where it was being added.

6015430: Reduce platform-like buildflags in sandbox code
Refs: https://chromium-review.googlesource.com/c/chromium/src/+/6015430

* 6039836: Migrate Command::IsMediaKey to be a member of ui::Accelerator
https://chromium-review.googlesource.com/c/chromium/src/+/6039836

* 6038659: [CodeHealth] Clean up the feature ZstdContentEncoding
https://chromium-review.googlesource.com/c/chromium/src/+/6038659

* chore: bump chromium in DEPS to 133.0.6862.0

* chore: update patches

* 72747: crypto: switch to C++
https://boringssl-review.googlesource.com/c/boringssl/+/72747

* fixup! 72747: crypto: switch to C++ https://boringssl-review.googlesource.com/c/boringssl/+/72747

* chore: gen libc++ filenames

* 6042601: [shared storage] Implement with_lock option for methods from response headers
https://chromium-review.googlesource.com/c/chromium/src/+/6042601

* chore: bump chromium in DEPS to 133.0.6864.0

* chore: bump chromium in DEPS to 133.0.6866.0

* chore: bump chromium in DEPS to 133.0.6868.0

* chore: bump chromium in DEPS to 133.0.6870.0

* chore: bump chromium in DEPS to 133.0.6872.0

* chore: bump chromium in DEPS to 133.0.6874.0

* chore: bump chromium in DEPS to 133.0.6876.0

* 6039992: Fix false activation logic for context menu. | https://chromium-review.googlesource.com/c/chromium/src/+/6039992

* chore: update patches

* chore: update patches

* chore: bump chromium in DEPS to 133.0.6878.0

* chore: update patches

* [Build] Organize //components/dbus into a single component

Xref: https://chromium-review.googlesource.com/c/chromium/src/+/6055280

* Merge //components/dbus/* into a single //components/dbus, which
  matches how most components are organized. This avoids having
  many small shared libraries which incurs unnecessary overhead.
* Limit visibility of //components/dbus/* to //components/dbus

* fixup! Update _LIBCPP_ABI_VERSION to always have a default value while keeping unstable false due to changes in llvm llvm/llvm-project#112094

* 6040416: Let s know which widget the input came on. | https://chromium-review.googlesource.com/c/chromium/src/+/6040416

* 6056267: [MPArch guest view] Fix authentication for MPArch guests | https://chromium-review.googlesource.com/c/chromium/src/+/6056267

* make_span() is deprecated: https://issues.chromium.org/issues/341907909

* fixup: https://issues.chromium.org/issues/341907909

* chore: delete extra bracket from removing make_span commit

* fixup: 6059305: Make WTF::UTF8ConversionMode a scoped enum | https://chromium-review.googlesource.com/c/chromium/src/+/6059305

* 6051058: CookieInclusionStatus: Remove ctors which bypass invariants | https://chromium-review.googlesource.com/c/chromium/src/+/6051058

* 6038981: Remove most remaining CHECK(false)s | https://chromium-review.googlesource.com/c/chromium/src/+/6038981

* build: use third_party/simdutf in Node.js

* chore: node ./script/gen-libc++-filenames.js

* chore: fix strict-cast conversion error in subspan()

Xref: https://chromium-review.googlesource.com/c/chromium/src/+/6044946

* chore: fix strict-cast conversion error in base::as_bytes()

Xref: https://chromium-review.googlesource.com/c/chromium/src/+/6044946

* chore: fix strict-cast conversion error in span.split_at()

Xref: https://chromium-review.googlesource.com/c/chromium/src/+/6044946

* chore: use shorthand target name

* chore: better docs in build_add_public_config_simdutf_config.patch

---------

Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: clavin <[email protected]>
Co-authored-by: alice <[email protected]>
Co-authored-by: Charles Kerr <[email protected]>
* fix: context-menu emitted twice

* refactor: simplify disabling draggable regions

* cleanup
Co-authored-by: electron-appveyor-updater[bot] <161660339+electron-appveyor-updater[bot]@users.noreply.github.com>
* chore: update vm module warning

* Update lib/renderer/init.ts

Co-authored-by: Keeley Hammond <[email protected]>

---------

Co-authored-by: Keeley Hammond <[email protected]>
* build: test windows runner

* build: try build windows on windows?

* build: take win/cross changes

* build: use bash as default shell always

* build: configure git for windows build tools

* build: bash as default

* build: configure windows correctly

* build: use sha1sum

* build: force windows cipd init and python3 existence

* just pain

* build: restore cache on windows

* build: use build-tools gclient

* build: sync gclient vars to build windows job

* build: output depshash for debugging

* build: past sam was a silly goose

* build: depshash logging

* build: force lf endings for lock and DEPS

* build: platform strings are hard

* build: checkout on windows host

* sup

* no check

* idk

* sigh

* ...

* no double checkout

* build: yolo some stuff

* build: run gn-check for windows on linux hosts for speed

* use container...

* cry ?

* build: e d

* e d

* no log

* fix toolchain on windows cross check

* build: use powershell to add mksnapshot_args

* build: enable x86 and arm64 windows builds too

* clean up

* maybe not needed

* build: keep action around for post step

* build: configure git global on win

* build: ia32 zip manifest

* build: no patch depot_tools for tests

* build: get arm64 windows closer to working

* build: windows tar is ass

* 32 bit on 32 bit

* maybe bash

* build: set up nodejs

* correct windows sharding

* fix some spec runner stuff

* fix windows tests

* overwrite -Force

* sigh

* screen res

* wat

* logs

* ... more logs

* line endings will be the death of me

* remove 1080p force thing

* vsctools + logging

* disable some fullscreen tests on GHA

* no progress

* run all CI

* install visual studio on arm64

* windows hax for non windows

* maybe arm sdk

* clean up depshash logic

* build: use single check per platform

* ensure clean args

* fix loop

* remove debug

* update default build image sha for dispatch

* plzzzz

* one more try

* arm64 vctools

* sad

* build: fix non-dispatch windows gn check

* chore: debug datadog-ci location

* chore: update build-tools for newer toolchain

* chore: set path for datadog-ci

* try this

* chore: fixup gn check

* fixup gn-check some more

* fixup windows gn check

* chore: fixup windows gn check

* test: use cmd for Windows testing

* fixup use cmd for testing on Windows

* fixup windows GN check

* fixup npm config arch for x86

* Can we set test files via powershell

* fixup to set test files via powershell

* fixup set test files via powershell

* Don't check cross instance cache disk space on Windows

* Use separate step to set env variables for testing

* fixup Use separate step to set env variables for testing

* fixup Use separate step to set env variables for testing

* fixup Use separate step to set env variables for testing (AGAIN)

* use powershell if in powershell

* fixup use powershell if in powershell

* chore: remove no longer needed changes to depot_tools

xref: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/5669094
and https://chromium-review.googlesource.com/c/chromium/src/+/5844046

* chore: try using 7zip on Windows to extract tarball

* Revert "chore: try using 7zip on Windows to extract tarball"

This reverts commit c7432b6.

* test: debug failing tests on GHA windows

* fix: ftbfs when including simdjson in Node.js

(cherry picked from commit 48e44c4)

* chore: try to track down Windows testing hang

* use correct timeout

* try this

* see if this helps

* try to figure out why node is running

* shard tests to try to narrow down WOA lockup

* try to narrow down problem test

* Narrow down blocking test more

* do we need a combo to repro

* see if this cleans up the tests

* fixup navigator.usb test

* remove logging from problematic tests

* Revert "shard tests to try to narrow down WOA lockup"

This reverts commit a180658.

* remove logging

* debug keyboard test

* add timeout for Windows since arm64 sometimes hangs

* see if this helps

* put back original timeout

* try to use screenCapture to get screenshots of what is going on on WOA

* try using electron screencapture to debug WOA hang

* chore: turn off privacy experience

* run screenshot on both shards

* fixup screencap

* try to narrow down hanging spec

* chore: cleanup servers left open

* cleanup tests

* Revert "try to narrow down hanging spec"

This reverts commit a0f959f.

* cleanup test debugging

* fixup extensions spec

* cleanup unneeded items

* run wtf with 2 shards instead of 6

* Revert "run wtf with 2 shards instead of 6"

This reverts commit ca2d282.

* debug windows version on woa

* dump more info

* Get detailed CPU info

* revert debugging

* use same args as AppVeyor WOA for GHA WOA

* fixup use same args as AppVeyor WOA for GHA WOA

* fixup use same args as AppVeyor WOA for GHA WOA

* try to track down which tests trigger hang

* one or more of these combinations should hang

* break up web contents spec to find hang

* further break down api-web-contents to find hang

* test: ensure all webContents are closed

* test: fix require is not defined error

* see if api-web-contents spec is now good

* test: ensure all webContents are closed

* Revert "try to track down which tests trigger hang"

This reverts commit 07298d6.

* chore: use alternate location for windows toolchain

* Reapply "try to track down which tests trigger hang"

This reverts commit 0321f76.

* try to narrow down problem test

* fix TEST_SHARD env var

* no, really fix TEST_SHARD env var

* see if this fixes it

* test: cleanup any remaining windows and webcontents

* see if new cleanup helps

* dont destroy webcontents for now

* fixup dont destroy webcontents for now

* Only cleanup right before process.exit

* see if this fixes the hang

* actually destroy webcontents

* Revert "Reapply "try to track down which tests trigger hang""

This reverts commit cdee7de.

* see if this helps

* Revert "see if this helps"

This reverts commit 9a15a69.

* Is it all about the web contents?

* it is all about the webcontents

but which one?

* Narrow down problem webcontents test

* try to speed up git install on WOA

* disable problematic test on WOA

* remove debugging

* remove debugging from choco installs

* Revert "disable problematic test on WOA"

This reverts commit e060fb0.

* Revert "remove debugging"

This reverts commit f18dd8b.

* run against all the tests in the failing shard

* don't run visibility tests first

* remove debugging

* 3 is a magic number

* Revert "3 is a magic number"

This reverts commit 36b91cc.

* match what Appveyor runs exactly

* Revert "match what Appveyor runs exactly"

This reverts commit 7260dd4.

* chore: sort files alphabetically

* find out what spec is leaving stuff open

* chore: Checkout PR HEAD commit

 instead of merge commit

* try using app.exit instead of process.exit

* test: cleanup BrowserWindows and webContents

* Revert "chore: sort files alphabetically"

This reverts commit d9e217f.

* chore: use win32 to match process.platform

Needed for build-tools to download from PRs

* chore: cache yarn dir

* fixup cache yarn

* fixup use win32 to match process.platform

* fixup use win32 to match process.platform

* fixup cache yarn

* Add debugging for WOA hang

* Add debugging for failing keyboard lock test

* Revert "Add debugging for WOA hang"

This reverts commit 8df03d5.

* try using process.kill

* add more debugging to keyboard.lock test

* Revert "Add debugging for failing keyboard lock test"

* remove debugging

* test: disable keyboard.lock on Windows

* test: disable fullscreen tests on Windows

* test: only force test suite exit on WOA

* fixup test: only force test suite exit on WOA

* cleanup tests

* extract yarn caching/install to action

* try using bash to run windows tests

* remove left over debugging

* standardize on 'win' for Windows builds

* use 'x86' for arch for manifest files

* fixup try using bash to run windows tests

* fixup use 'x86' for arch for manifest files

* standardize on 'win' for Windows builds

* fixup use 'x86' for arch for manifest files

* fixup try using bash to run windows tests

---------

Co-authored-by: John Kleinschmidt <[email protected]>
Co-authored-by: Charles Kerr <[email protected]>
`ReadUnicodeCharacter` updates index to the last character read, and not after it. We need to manually increment it to move to the next character.

It also doesn't validate that the index is valid, so we need to check that index is within bounds.

Refs: #44336
chore: update build tools to correct sha
Update window-setup.ts

The message should simply read "is not supported" or, alternatively, "is not, and will not, be supported", but not "is and will not be supported".
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.27.6 to 3.27.9.
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@aa57810...df409f7)

---
updated-dependencies:
- dependency-name: github/codeql-action
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…on windows on Windows (#45000)

* fix: add patch to fix desktopCapturer.getSources not returning electron window on Windows

* add chromium link

* Update patches/chromium/fix_desktop_capturer_show_own_window.patch

Co-authored-by: Keeley Hammond <[email protected]>

* fix on electron side

* set flag to true

* wrong capturer

---------

Co-authored-by: Keeley Hammond <[email protected]>
* chore: bump chromium in DEPS to 133.0.6887.0

* chore: update render_widget_host_view_base.patch

trivial manual intervention needed due to header context shear

Xref: https://chromium-review.googlesource.com/c/chromium/src/+/5952851

* chore: update osr_shared_texture_remove_keyed_mutex_on_win_dxgi.patch

trivial manual intervention needed due to header context shear

Xref: https://chromium-review.googlesource.com/c/chromium/src/+/6068570

* chore: e patches all

* Remove ClipboardFormatType::GetType()

Xref: https://chromium-review.googlesource.com/c/chromium/src/+/6075792

* Remove raw byte range methods from network::ResourceRequestBody

Xref: https://chromium-review.googlesource.com/c/chromium/src/+/6038757

* fix: update patches/chromium/fix_crash_loading_non-standard_schemes_in_iframes.patch:wq

Refs https://issues.chromium.org/issues/40092527

* fix: windows gn check

* chore: update patches/chromium/render_widget_host_view_base.patch

---------

Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <[email protected]>
Co-authored-by: deepak1556 <[email protected]>
Bumps [actions/checkout](https://github.com/actions/checkout) from 4.1.6 to 4.2.2.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@v4.1.6...11bd719)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* test: renable GHA on Windows disabled tests

* test: close edge after shell.openExternal

* test: close edge sync after shell.openExternal
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4.4.3 to 4.5.0.
- [Release notes](https://github.com/actions/upload-artifact/releases)
- [Commits](actions/upload-artifact@b4b15b8...6f51ac0)

---
updated-dependencies:
- dependency-name: actions/upload-artifact
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.27.9 to 3.28.0.
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@df409f7...48ab28a)

---
updated-dependencies:
- dependency-name: github/codeql-action
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
#45143)

* perf: cache whether or not ELECTRON_DEBUG_NOTIFICATIONS env var is set

* chore: remove unused #include
* chore: bump chromium in DEPS to 133.0.6902.0

* chore: bump chromium in DEPS to 133.0.6903.0

* chore: update patches

* Update PdfViewer Save File Picker to use showSaveFilePicker.

Refs https://chromium-review.googlesource.com/c/chromium/src/+/6074308

* Code Health: Clean up stale MacWebContentsOcclusion

Refs https://chromium-review.googlesource.com/c/chromium/src/+/6078344

* Change RenderProcessHost::GetID to RenderProcessHost::GetDeprecatedID

Refs https://chromium-review.googlesource.com/c/chromium/src/+/6065543

* [WebRTC] Make WebRTC IP Handling policy a mojo enum

Refs https://chromium-review.googlesource.com/c/chromium/src/+/6063620

* chore: gen filenames.libcxx.gni

* Remove allow_unsafe_buffers pragma in //printing

Refs https://chromium-review.googlesource.com/c/chromium/src/+/6092280

* refactor: to use ChildProcessId where possible

Refs https://issues.chromium.org/issues/379869738

* [Win] Update TabletMode detection code

Refs https://chromium-review.googlesource.com/c/chromium/src/+/6003486

* chore: bump chromium in DEPS to 133.0.6905.0

* chore: update patches

* Reland "Move global shortcut listener to //ui/base"

Refs https://chromium-review.googlesource.com/c/chromium/src/+/6099035

* [shared storage] Implement the batch `with_lock` option for response header

Refs https://chromium-review.googlesource.com/c/chromium/src/+/6072742

* chore: bump chromium in DEPS to 133.0.6907.0

* chore: bump chromium in DEPS to 133.0.6909.0

* chore: bump chromium in DEPS to 133.0.6911.0

* chore: bump chromium in DEPS to 133.0.6912.0

* chore: update patches

* WebUI: Reveal hidden deps to ui/webui/resources.

Refs https://chromium-review.googlesource.com/c/chromium/src/+/6096291

* chore: bump chromium in DEPS to 133.0.6913.0

* chore: bump chromium in DEPS to 133.0.6915.0

* Code Health: Clean up stale base::Feature "AccessibilityTreeForViews"

Refs https://chromium-review.googlesource.com/c/chromium/src/+/6104174

Co-authored-by: David Sanders <[email protected]>

* fix: remove fastapitypedarray usage

* chore: update patches

* chore: script/gen-libc++-filenames.js

* Code Health: Clean up stale base::Feature "WinRetrieveSuggestionsOnlyOnDemand"

Refs https://chromium-review.googlesource.com/c/chromium/src/+/6109477

* fix: empty suggestions with windows platform checker

Amends the fix from #29690
since the feature flag is no longer available. We follow the
same pattern as //chrome/browser/renderer_context_menu/spelling_menu_observer.cc
to generate the suggestion list on demand when context menu action
is invoked.

Co-authored-by: David Sanders <[email protected]>

* fixup! fix: empty suggestions with windows platform checker

* fixup! fix: empty suggestions with windows platform checker

* revert: 6078344: Code Health: Clean up stale MacWebContentsOcclusion | https://chromium-review.googlesource.com/c/chromium/src/+/6078344

* Revert "revert: 6078344: Code Health: Clean up stale MacWebContentsOcclusion | https://chromium-review.googlesource.com/c/chromium/src/+/6078344"

This reverts commit 9cacda4.

* chore: bump to 133.0.6920.0, update patches

* Revert "6078344: Code Health: Clean up stale MacWebContentsOcclusion"

Refs: https://chromium-review.googlesource.com/c/chromium/src/+/6078344

* fixup! Update PdfViewer Save File Picker to use showSaveFilePicker.

---------

Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: deepak1556 <[email protected]>
Co-authored-by: David Sanders <[email protected]>
Co-authored-by: Keeley Hammond <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.