119
edits
Media/WebRTC/libwebrtc Update Process: Difference between revisions
Jump to navigation
Jump to search
Media/WebRTC/libwebrtc Update Process (view source)
Revision as of 21:00, 30 June 2023
, 30 June 2023move pushing to elm step under the update steps section
(Change section levels to help with better labeling) |
(move pushing to elm step under the update steps section) |
||
| Line 40: | Line 40: | ||
* Run loop-ff.sh | * Run loop-ff.sh | ||
bash dom/media/webrtc/third_party_build/loop-ff.sh | bash dom/media/webrtc/third_party_build/loop-ff.sh | ||
* Push to elm - after the loop-ff.sh script completes with the message <code>===loop-ff=== Completed fast-foward to {short-sha}</code>, run the following step to push the new version of libwebrtc to elm: | |||
hg push -r tip | |||
== Operational Notes == | == Operational Notes == | ||
=== Reacting to loop-ff.sh === | === Reacting to loop-ff.sh === | ||
Three main types of errors will cause <code>loop-ff.sh</code> to exit: the first is a git rebase conflict, the second is a failure to regenerate build files (due to BUILD.gn changes), and the third is a build error due to API changes in upstream code. | Three main types of errors will cause <code>loop-ff.sh</code> to exit: the first is a git rebase conflict, the second is a failure to regenerate build files (most often due to BUILD.gn changes or missing/added files), and the third is a build error due to API changes in upstream code. | ||
* When fixing rebase errors or making other changes to fix build issues in moz-libwebrtc (any changes under third_party/libwebrtc), mercurial commit messages follow the pattern: | * When fixing rebase errors or making other changes to fix build issues in moz-libwebrtc (any changes under third_party/libwebrtc), mercurial commit messages follow the pattern: | ||
| Line 64: | Line 67: | ||
=== General tips === | === General tips === | ||
* Stopping the loop-ff.sh manually is best done when in the <code>Test build</code> phase using Ctrl-c. | * Stopping the loop-ff.sh manually is best done when in the <code>Test build</code> phase using Ctrl-c. | ||
* Rather than waiting until the end of the process update process, you may push to elm to confirm build fixes, or for others to follow along. It is best to push a commit that successfully builds, but this isn't a hard and fast rule. Sometimes, it may be helpful to push a commit that is broken to get help from others, or when the fixes are complicated enough that you feel a review is necessary. | |||
* If loop-ff.sh reveals an issue that is best dealt with in a followup, one can commit a temporary patch marked with <code>REPO-elm</code> in the first line of its description, i.e. the "title". The temporary commit allows loop-ff.sh to continue, whereas <code>REPO-elm</code> makes sure the commit cannot be pushed to any other mozilla repo than elm (and try). | * If loop-ff.sh reveals an issue that is best dealt with in a followup, one can commit a temporary patch marked with <code>REPO-elm</code> in the first line of its description, i.e. the "title". The temporary commit allows loop-ff.sh to continue, whereas <code>REPO-elm</code> makes sure the commit cannot be pushed to any other mozilla repo than elm (and try). | ||
* While loop-ff.sh is running, in a separate terminal window it may be helpful to see the overall progress by running: | * While loop-ff.sh is running, in a separate terminal window it may be helpful to see the overall progress by running: | ||
tail -f .moz-fast-forward/logs/log-loop-ff.txt | grep loop-ff | tail -f .moz-fast-forward/logs/log-loop-ff.txt | grep loop-ff | ||
* [[libwebrtc GYP generated Java files|GYP generated Java files]] | * [[libwebrtc GYP generated Java files|GYP generated Java files]] | ||
* If instructed to run [https://searchfox.org/mozilla-central/rev/3b707c8fd7e978eebf24279ee51ccf07895cfbcb/dom/media/webrtc/third_party_build/extract-for-git.py#9-12 extract-for-git.py], note that <code>loop-ff.sh</code> has more context than <code>verify_vendoring.sh</code> and offers information that is relevant: Specifically, the | * If instructed to run [https://searchfox.org/mozilla-central/rev/3b707c8fd7e978eebf24279ee51ccf07895cfbcb/dom/media/webrtc/third_party_build/extract-for-git.py#9-12 extract-for-git.py], note that <code>loop-ff.sh</code> has more context than <code>verify_vendoring.sh</code> and offers information that is relevant: Specifically, the guidance about <code>tip::tip</code>: | ||
If you have previously run loop-ff.sh successfully, there may be a new | If you have previously run loop-ff.sh successfully, there may be a new | ||
change to third_party/libwebrtc that should be extracted and added to | change to third_party/libwebrtc that should be extracted and added to | ||
| Line 77: | Line 81: | ||
git am mailbox.patch) | git am mailbox.patch) | ||
:Replace <code>tip</code> here with your (fix-xxx) mercurial patch, if it is not at tip (e.g. if it is followed by (fix-xxx) - moz.build file updates). | |||
=== Recovering from errors === | === Recovering from errors === | ||
| Line 86: | Line 90: | ||
=== Review === | === Review === | ||
* Simple changes don't require individual review, but if you'd feel better about getting reviewed, push the commit | * Simple changes don't require individual review, but if you'd feel better about getting reviewed, push the vendored commit to elm (which may break all the builds). Then put the patch up for review. After r+, land it using Lando to elm. | ||
=== Daily rebase on elm (after completing loop-ff process) === | === Daily rebase on elm (after completing loop-ff process) === | ||