24
edits
Media/WebRTC/libwebrtc Update Process: Difference between revisions
Media/WebRTC/libwebrtc Update Process (view source)
Revision as of 18:36, 30 June 2023
, 30 June 2023Break out Reacting to loop-ff.sh section to highlight the three types of failures to deal with
(reword third category to: failure to regenerate build files) |
(Break out Reacting to loop-ff.sh section to highlight the three types of failures to deal with) |
||
| Line 62: | Line 62: | ||
bash dom/media/webrtc/third_party_build/push_official_branch.sh | bash dom/media/webrtc/third_party_build/push_official_branch.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. | |||
1. 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: | |||
Bug {current-fast-forward-bug-number} - (fix-{upstream-sha}) {description} | Bug {current-fast-forward-bug-number} - (fix-{upstream-sha}) {description} | ||
| Line 75: | Line 75: | ||
--repo-path $MOZ_LIBWEBRTC_SRC \ | --repo-path $MOZ_LIBWEBRTC_SRC \ | ||
--target-branch-head $MOZ_TARGET_UPSTREAM_BRANCH_HEAD ) | --target-branch-head $MOZ_TARGET_UPSTREAM_BRANCH_HEAD ) | ||
2. When making changes to fix Mozilla code (code outside of third_party/libwebrtc) in response to changes upstream, mercurial commit messages follow the pattern: | |||
Bug {current-fast-forward-bug-number} (MOZ) - {description} | Bug {current-fast-forward-bug-number} (MOZ) - {description} | ||
3. If instructed to run <code>commit-build-file-changes.sh</code>, its auto-generated mercurial commit messages follow the pattern: | |||
Bug {current-fast-forward-bug-number} - (fix-{upstream-sha}) {description} - moz.build file updates | |||
If multiple kinds of changes are needed, commit hygiene is appreciated: (MOZ) patches first, followed by the (fix-xxx) commit, followed by the script-generated "(fix-xxx) - moz.build file updates" — This order might require some effort if things don't build successfully right away (commit + build + amend). | |||
=== Operational notes === | |||
* Running <code>prep-repo.sh</code> with a fresh github clone of moz-libwebrtc will likely display instructions on how to add recent moz-central changes made in <code>third_party/libwebrtc</code> to the top of the patch stack in github. This is expected and necessary for successfully vendoring changes into <code>third_party/libwebrtc</code>. | |||
* 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: | ||