Media/WebRTC/libwebrtc Update Process: Difference between revisions

From MozillaWiki
< Media‎ | WebRTC
Jump to navigation Jump to search
(Add Transition Plan Section and Link\)
(add initial operation checklist and steps to reset elm)
Line 1: Line 1:
This page will describe the process for updating the in tree, vendored copy of libwebrtc.
This page describes the process for updating the in tree, vendored copy of libwebrtc using the fast-forward scripts.


== Transition Plan ==
== Operation Checklist ==
2H 2020 will be the first time that we use the new update process. In order to start that work, the current copy that lives in tree will be made to fit the new process. That work is documented in [[Media/WebRTC/libwebrtc_Update_Process_Transition_Plan]].
=== 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.
 
- 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
 
=== 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 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
 
== Resetting Elm ==
Before each new merge cycle. Elm needs to be reset to Central, and the floating patches need to be reapplied.
# Ensure you have filed a bug for the next merge cycle, and further ensure that the next merge cycle bug has the previous merge cycle bug as a dependency.
# Make sure you have a local checkout of Elm which includes the floating patches.
# File a bug as a clone of [https://bugzilla.mozilla.org/show_bug.cgi?id=1789675 Bug 1789675] and add your new bug as dependency to the next merge cycle bug.
# Wait for the repo admins to reset the repository.
# Mark the floating arc config patch with a bookmark. If the patch had id `5e8481a558fb` then one would run <syntaxhighlight lang="Bash">hg bookmark -r 5e8481a558fb ARC_CONFIG_FLOAT</syntaxhighlight>
# Pull the new head of Elm. <syntaxhighlight lang="Bash">hg pull</syntaxhighlight>.
# Rebase the floating patches onto the new checkout of Elm, then checkout the new tip. <syntaxhighlight lang="Bash">
hg rebase --keep -s ARC_CONFIG_FLOAT -d elm && \
hg co tip && \
hg bookmark ARC_CONFIG_FLOAT
</syntaxhighlight>
# Push the floating patches to Elm. <syntaxhighlight lang="Bash">hg push --bookmark=ARC_CONFIG_FLOAT</syntaxhighlight>
# Celebrate

Revision as of 22:08, 19 December 2022

This page describes the process for updating the in tree, vendored copy of libwebrtc using the fast-forward scripts.

Operation Checklist

Prerequisites

- Create a new bug for the fast-forward update. It should depend on the previous fast-forward bug. Bug 1800920 is an example.

- Builds are done after vendoring in each commit. Having a .mozconfig 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

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 dom/media/webrtc/third_party_build/loop-ff.sh

Operational notes

- Running prep-repo.sh with a fresh github clone of moz-libwebrtc will likely display instructions on how to add recent moz-central changes made in third_party/libwebrtc to the top of the patch stack in github. This is expected and necessary for successfully vendoring changes into third_party/libwebrtc.

- Two main types of errors will cause loop-ff.sh 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

Resetting Elm

Before each new merge cycle. Elm needs to be reset to Central, and the floating patches need to be reapplied.

  1. Ensure you have filed a bug for the next merge cycle, and further ensure that the next merge cycle bug has the previous merge cycle bug as a dependency.
  2. Make sure you have a local checkout of Elm which includes the floating patches.
  3. File a bug as a clone of Bug 1789675 and add your new bug as dependency to the next merge cycle bug.
  4. Wait for the repo admins to reset the repository.
  5. Mark the floating arc config patch with a bookmark. If the patch had id `5e8481a558fb` then one would run 
    hg bookmark -r 5e8481a558fb ARC_CONFIG_FLOAT
  6. Pull the new head of Elm. 
    hg pull
    .
  7. Rebase the floating patches onto the new checkout of Elm, then checkout the new tip. 
    hg rebase --keep -s ARC_CONFIG_FLOAT -d elm && \
hg co tip && \
hg bookmark ARC_CONFIG_FLOAT
  8. Push the floating patches to Elm. 
    hg push --bookmark=ARC_CONFIG_FLOAT
  9. Celebrate
Retrieved from "https://wiki.allizom.org/index.php?title=Media/WebRTC/libwebrtc_Update_Process&oldid=1244948"