122
edits
Media/WebRTC/libwebrtc Update Process: Difference between revisions
Media/WebRTC/libwebrtc Update Process (view source)
Revision as of 20:41, 30 June 2023
, 30 June 2023Change section levels to help with better labeling
(Reorg the update steps using bulleted items so that clarifying comments can be adjacent to the relevant step) |
(Change section levels to help with better labeling) |
||
| Line 1: | Line 1: | ||
This page describes the process for updating the in tree, vendored copy of libwebrtc using the fast-forward scripts. | This page describes the process for updating the in tree, vendored copy of libwebrtc using the fast-forward scripts. | ||
== Prerequisites == | |||
* Create a new bug for the fast-forward update. It should depend on the previous fast-forward bug. [https://bugzilla.mozilla.org/show_bug.cgi?id=1800920 Bug 1800920] is an example. | * Create a new bug for the fast-forward update. It should depend on the previous fast-forward bug. [https://bugzilla.mozilla.org/show_bug.cgi?id=1800920 Bug 1800920] is an example. | ||
* Before each new merge cycle elm needs to be reset to Central. | * Before each new merge cycle elm needs to be reset to Central. | ||
| Line 15: | Line 14: | ||
hg clone --stream ssh://hg.mozilla.org/projects/elm | hg clone --stream ssh://hg.mozilla.org/projects/elm | ||
== Update steps == | |||
* Start from the elm checkout | * Start from the elm checkout | ||
cd elm | cd elm | ||
| Line 42: | Line 41: | ||
bash dom/media/webrtc/third_party_build/loop-ff.sh | bash dom/media/webrtc/third_party_build/loop-ff.sh | ||
== 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 (due to BUILD.gn changes), and the third is a build error due to API changes in upstream code. | ||
| Line 62: | Line 62: | ||
If multiple kinds of changes are needed to fix build errors, commit hygiene is a must: (MOZ) patches contain changes to files outside of third_party/libwebrtc, (fix-xxx) commits contain changes to third_party/libwebrtc files, and finally "(fix-xxx) ... - moz.build file updates" contain only third_party/libwebrtc moz.build changes. | If multiple kinds of changes are needed to fix build errors, commit hygiene is a must: (MOZ) patches contain changes to files outside of third_party/libwebrtc, (fix-xxx) commits contain changes to third_party/libwebrtc files, and finally "(fix-xxx) ... - moz.build file updates" contain only third_party/libwebrtc moz.build changes. | ||
=== | === General tips === | ||
* Stopping the loop-ff.sh manually is best done when in the <code>Test build</code> phase using Ctrl-c. | |||
* 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: | ||
| Line 78: | Line 79: | ||
* 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). | * 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 === | ||
* If a particularly complicated rebase conflict is encountered, it is possible to start over the most recent vendoring step by resetting some state and restoring the patch stack. | * If a particularly complicated rebase conflict is encountered, it is possible to start over the most recent vendoring step by resetting some state and restoring the patch stack. | ||
rm .moz-fast-forward/*.resume # resets the resume logic in loop-ff.sh | rm .moz-fast-forward/*.resume # resets the resume logic in loop-ff.sh | ||
| Line 87: | Line 86: | ||
=== Review === | === Review === | ||
* Simple changes don't require individual review, but if you'd feel better about getting reviewed, push the commit prior to elm (which will break all the builds). Then put the patch up for review. After r+, land it using Lando to elm. | * Simple changes don't require individual review, but if you'd feel better about getting reviewed, push the commit prior to elm (which will break all the builds). Then put the patch up for review. After r+, land it using Lando to elm. | ||