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

1,118 bytes added , 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 225: / Line 233: @@
 * 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 ==
+== Moving third_party/libwebrtc/third_party/* to third_party/* ==
-* Prerequisites
+=== Motivation ===
-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.
+(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.
- hg clone https://hg.mozilla.org/projects/elm
+* Reduce the number of libwebrtc patches, with an emphasis on build patches
- (cd elm && ./mach bootstrap --application-choice=browser && ./mach build)
+* Reduce the merge process complexity
- git clone https://github.com/mozilla/libwebrtc moz-libwebrtc
+* Reduce our response time to security issues
-On macOS, the python module <code>requests</code> should be installed.
+* Uplifting patches
- pip install requests
-* Update steps
+Additionally, resolving these issues would assist with broader product goals.
- # Start from the elm checkout
+* Improve performance
- cd elm
+* Reduce build time
- # 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
+==== Patch Reduction ====
-- 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>.
+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.
-- 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.
+==== 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.
-- When making changes to fix build issues in moz-libwebrtc, mercurial commit messages follow the pattern:
+=== Approach ===
- Bug xxx - (fix-{upstream-sha}) {description}
+We will need to employ several strategies in order to create a robust build environment.
+# We will vendor the libraries that libwebrtc requires, but are not provided on our older supported platforms. These dependencies can be kept up to date with `updatebot`.
-- When making changes to fix Mozilla code in response to changes upstream, mercurial commit messages follow the pattern:
+# We will move vendored shared dependencies from `libwebrtc/third_party` into `third_party`.
- Bug xxx (MOZ) - {description}
+As simple as this plan sounds it is complicated by mixed build systems and the current method of importing dependencies into libwebrtc. Eliminating duplicate dependencies also has the risk of running into incompatible version expectations by dependency consumers.
-- 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 ===
-=== Approach ===
 === Notes ===
 # (lib)webrtc dependency pinning