Media/WebRTC/libwebrtc Update Process/automation plan: Difference between revisions

← Older edit

Media/WebRTC/libwebrtc Update Process/automation plan (view source)

Revision as of 22:24, 19 December 2022

330 bytes removed , 19 December 2022

Add note at top to redirect users to the fast-forward checklist steps, and remove the checklist and resetting elm sections

Mfroman

119

edits

@@ Line 1: / Line 1: @@
+<big><span style="color: red">Note: If you are trying to do a fast-forward update please go</span> [[Media/WebRTC/libwebrtc_Update_Process|here]].
+</big><br />
+<big><span style="color: red">Note: If you are trying to do a fast-forward update please go</span> [[Media/WebRTC/libwebrtc_Update_Process|here]].
+</big><br />
+<big><span style="color: red">Note: If you are trying to do a fast-forward update please go</span> [[Media/WebRTC/libwebrtc_Update_Process|here]].
+</big>
 This describes the rough plan to document and automate the process to "fast-forward" through webrtc.org libwebrtc change-sets to bring Firefox's libwebrtc version as close as possible to Chrome.  This page will be updated as new information is discovered.
@@ Line 224: / Line 232: @@
    requiring lots of network.
 * Do we want to add our fixup-patch to the moz-libwebrtc branch and move the branch forward in the official repo to make it more clear what was previously vendored?
-== Operation Checklist ==
-* Prerequisites
-Builds are done after vendoring in each commit.  Having a <code>.mozconfig</code> file that enables cache (either sccache or ccache) will improve the performance of the scripts.
- hg clone https://hg.mozilla.org/projects/elm
- (cd elm && ./mach bootstrap --application-choice=browser && ./mach build)
- git clone https://github.com/mozilla/libwebrtc moz-libwebrtc
-On macOS, the python module <code>requests</code> should be installed.
- pip install requests
-* Update steps
- # Start from the elm checkout
- cd elm
- # Prepare the github repo
- bash dom/media/webrtc/third_party_build/prep_repo.sh
- # Run loop-ff.sh
- bash bash dom/media/webrtc/third_party_build/loop-ff.sh
-* 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>.
-- Two main types of errors will cause <code>loop-ff.sh</code> to exit; the first is a rebase conflict, the second is a build error due to api changes in upstream code.
-- When making changes to fix build issues in moz-libwebrtc, mercurial commit messages follow the pattern:
- Bug xxx - (fix-{upstream-sha}) {description}
-- When making changes to fix Mozilla code in response to changes upstream, mercurial commit messages follow the pattern:
- Bug xxx (MOZ) - {description}
-- While loop-ff.sh is running, in a separate terminal window it may be helpful to see the overall progress by running:
- tail -f ~/log-loop-ff.txt | grep loop-ff
 == Moving third_party/libwebrtc/third_party/* to third_party/* ==
 === Motivation ===
-(lib)webrtc and Firefox share a number of dependencies. Both projects expect that their dependencies will live under a `third_party` in their respective project roots. libwebrtc is a dependency of Firefox, presenting an organizational problem. Additionally there are libraries that are expected to exist in the deployment environments. This can pose a problem where Firefox supports systems with older versions of those libraries than libwebrtc does. This cluster of issues runs counter to a number of our WebRTC team Q4 goals.
+(lib)webrtc and Firefox share a number of dependencies. Both projects expect that their dependencies will live under a `third_party` in their respective project roots. As a dependency of libwebrtc, this presents an organizational problem. Additionally there are libraries that are expected to exist in the deployment environments. This can pose a problem where Firefox supports systems with older versions of those libraries than libwebrtc does. Resolving this cluster of issues would directly impact a number of our WebRTC team Q4 goals.
 * Reduce the number of libwebrtc patches, with an emphasis on build patches
 * Reduce the merge process complexity
@@ Line 269: / Line 244: @@
 * Improve performance
 * Reduce build time
+==== Patch Reduction ====
+We carry a number of libwebrtc build system patches. These patches create numerous merge conflicts each merge cycle. Problematically, Google is unable to perform CI builds with our [https://searchfox.org/mozilla-central/rev/7b5c93295ea5071d3cc5b3ac21c6e8e654f69e1b/third_party/libwebrtc/BUILD.gn#148 build_with_mozilla flag]. They have expressed interest in removing this flag. In order to remove this flag entirely we need to eliminate our build patches. We could then express our build as a series of feature flags within their build system. Perhaps they would be willing to run that flag set in their CI.
+==== Merge Complexity ====
+Updating the dependencies is tied directly to the merge process. Decoupling can be achieved by moving the dependencies into `third_party` and placing them under control of `updatebot`. This would create a smaller merge with less risk.
 === Approach ===