119
edits
Media/WebRTC/libwebrtc Update Process: Difference between revisions
Media/WebRTC/libwebrtc Update Process (view source)
Revision as of 18:46, 20 March 2024
, 20 March 2024add note about ability to stop during the rebase operation
(move pushing to elm step under the update steps section) |
(add note about ability to stop during the rebase operation) |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
== Prerequisites == | == Prerequisites == | ||
* NOTE: all steps below assume the user is in the bash shell. | |||
* 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 13: | Line 14: | ||
* Starting with a fresh clone of elm is recommended for each new chromium milestone. | * Starting with a fresh clone of elm is recommended for each new chromium milestone. | ||
hg clone --stream ssh://hg.mozilla.org/projects/elm | hg clone --stream ssh://hg.mozilla.org/projects/elm | ||
* Verify the most recent commit is the .arcconfig update. If the most recent commit doesn't look like "Bug xxx - FLOAT - REPO-elm - update .arcconfig repo callsign", run the following commands: | |||
./mach python dom/media/webrtc/third_party_build/restore_elm_arcconfig.py | |||
hg push -r tip | |||
== Update steps == | == Update steps == | ||
| Line 84: | Line 88: | ||
=== Recovering from errors === | === 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. Run these commands in a bash shell: | ||
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 | ||
hg revert third_party/libwebrtc && hg purge third_party/libwebrtc | hg revert third_party/libwebrtc && hg purge third_party/libwebrtc | ||
| Line 92: | Line 96: | ||
* 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. | * 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. | ||
== Waiting to land == | |||
=== Daily rebase on elm (after completing loop-ff process) === | === Daily rebase on elm (after completing loop-ff process) === | ||
Periodically, ideally daily to minimize surprises from mozilla-central, rebasing elm onto the latest mozilla-central is recommended after completing the update process. Rebases should be completed until the request for merging elm to moz-central is made. | Periodically, ideally daily to minimize surprises from mozilla-central, rebasing elm onto the latest mozilla-central is recommended after completing the update process. Rebases should be completed until the request for merging elm to moz-central is made. | ||
| Line 97: | Line 102: | ||
Historical note: we use a script to rebase because 1) it regenerates the moz.build files on the commits where those are changed. This avoids the typically massive rebase conflict if anyone has touched the build files. 2) it exports/imports each commit individually to limit rebase conflicts on individual patches, making it easier to deal with issues. | Historical note: we use a script to rebase because 1) it regenerates the moz.build files on the commits where those are changed. This avoids the typically massive rebase conflict if anyone has touched the build files. 2) it exports/imports each commit individually to limit rebase conflicts on individual patches, making it easier to deal with issues. | ||
bash dom/media/webrtc/third_party_build/elm_rebase.sh | bash dom/media/webrtc/third_party_build/elm_rebase.sh | ||
If one would like to make changes to the patch ordering during the rebase operation (say, for example, a fix-commit was necessary but is separated from the initial upstream patch), use the following command line: | |||
STOP_FOR_REORDER=1 bash dom/media/webrtc/third_party_build/elm_rebase.sh | |||
=== Requesting merge from elm to mozilla-central === | === Requesting merge from elm to mozilla-central === | ||