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 2,990 commits into
base: main
Choose a base branch
from
Open

[pull] main from electron:main #3

wants to merge 2,990 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.

codebytere and others added 30 commits August 20, 2024 16:49
* chore: set wg-releases as CODEOWNER for GHA build configs

* chore: change to wg-infra
* chore: bump chromium in DEPS to 130.0.6669.0

* 5789734: Consolidate all the accessibility scale factor utility code into one file

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

* 5798543: [autofill] Don't emit autofill audit reports if inspector not connected

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

* 5797073: [wasm] Spill all loop inputs before entering loop

https://chromium-review.googlesource.com/c/v8/v8/+/5797073

* chore: fixup patch indices

* 5795224: Version 13.0.0

https://chromium-review.googlesource.com/c/v8/v8/+/5795224

---------

Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
* docs: clarify icon value in Notification

* Update docs/api/notification.md

Co-authored-by: Erick Zhao <erick@hotmail.ca>

---------

Co-authored-by: Erick Zhao <erick@hotmail.ca>
Co-authored-by: electron-appveyor-updater[bot] <161660339+electron-appveyor-updater[bot]@users.noreply.github.com>
* fix: touch bar functionality on BaseWindow

* test: add test for BaseWindow.setTouchBar
chore: fix typos in 'docs/' folder.
fix: menu should allow focused BaseWindow
* chore: bump chromium in DEPS to 130.0.6671.0

* 5802591: [Partitioned Popins] (6) Add permissions policy for popin

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

* 5794132: [video pip] Move back to tab button to the header

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

---------

Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
chore: bump chromium in DEPS to 130.0.6672.0

Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
* feat: GPU shared texture offscreen rendering

* docs: clarify texture infos that passed by the paint event.

* feat: make gpu osr spec test optional

* fix: osr image compare

* fix: remove duplicate test

* fix: update patch file

* fix: code review

* feat: expose more metadata

* feat: use better switch design

* feat: add warning when user forget to release the texture.

* fix: typo

* chore: update patch

* fix: update patch

* fix: update patch description

* fix: update docs

* fix: apply suggestions from code review

Co-authored-by: Charles Kerr <charles@charleskerr.com>

* fix: apply suggested fixes

---------

Co-authored-by: Charles Kerr <charles@charleskerr.com>
chore: mentioned signed commit requirement
* fix: ensure bounds stability in OnWidgetBoundsChanged

* Update shell/browser/native_window_views.cc

Co-authored-by: Charles Kerr <charles@charleskerr.com>

---------

Co-authored-by: Charles Kerr <charles@charleskerr.com>
)

docs: titleBarOverlay is defined as a BaseWindow ctor option
chore: remove fix_disable_scope_reuse_associated_dchecks.patch
chore: remove unused asar::ClearArchives()

last use removed in Jun 2021 (b1d1ac6, #29293)
* chore: avoid double-call to url.scheme() in WebContentsZoomController::SetZoomMode()

* perf: use gurl.scheme_piece() in GetAppInfoHelperForProtocol()

* perf: use gurl.scheme_piece() in Browser::GetApplicationNameForProtocol()

* refactor: add std::less<> to HandlersMap

This lets us search it using string_view keys

* refactor: ProtocolRegistry::FindRegistered() now takes a std::string_view

* perf: use gurl.scheme_piece() in InspectableWebContents::LoadNetworkResource()

* refactor: ProtocolRegistry::FindIntercepted() now takes a std::string_view

* perf: use gurl.scheme_piece() in SimpleURLLoaderWrapper::GetURLLoaderFactoryForURL()

* perf: use gurl.scheme_piece() in ProxyingURLLoaderFactory::CreateLoaderAndStart()

* perf: use gurl.host_piece() in ElectronWebUIControllerFactory::GetWebUIType()

* perf: use gurl.host_piece() in ElectronWebUIControllerFactory::CreateWebUIControllerForURL()
Co-authored-by: electron-appveyor-updater[bot] <161660339+electron-appveyor-updater[bot]@users.noreply.github.com>
* chore: bump node in DEPS to v20.17.0

* module: disallow CJS <-> ESM edges in a cycle from require(esm)

nodejs/node#52264

* src: expose LookupAndCompile with parameters

nodejs/node#53886

* src: fix -Wshadow warning

nodejs/node#53885

* lib: convert WeakMaps in cjs loader with symbol properties

nodejs/node#52095

* src: reduce unnecessary serialization of CLI options in C++

nodejs/node#52451

* build: ensure v8_pointer_compression_sandbox is enabled on 64bit

nodejs/node#53884

* lib: improve error message when index not found on cjs

nodejs/node#53859

* src,lib: expose getCategoryEnabledBuffer to use on node.http

nodejs/node#53602

* deps: update c-ares to v1.32.2

nodejs/node#53865

* chore: fixup patch indices

* deps: update V8 to 12.2

nodejs/node#51362

* stream: Expose DuplexPair API

nodejs/node#34111

---------

Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet