Media/WebRTC/libwebrtc Update Process: Difference between revisions

we no longer need to push the branch to github
(in case the sheriffs forget, check for the .arcconfig commit)
(we no longer need to push the branch to github)
 
(4 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 first commit is the .arcconfig update.  If the first commit doesn't look like "Bug xxx - FLOAT - REPO-elm - update .arcconfig repo callsign", run the following commands:
* 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
   ./mach python dom/media/webrtc/third_party_build/restore_elm_arcconfig.py
   hg push -r tip
   hg push -r tip
Line 87: 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 101: 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 ===
Typically, immediately after the code-freeze has lifted, a request is made for the sheriffs to merge elm to mozilla-central.  This done via email, recently to Sebastian Hengst.
Typically, immediately after the code-freeze has lifted, a request is made for the sheriffs to merge elm to mozilla-central.  This done via email, recently to Sebastian Hengst.
=== Post-merge Steps ===
* After the merge from elm to mozilla-central is complete, the moz-libwebrtc github repo should be updated with the new branch of the commit stack for the new release.  There is script that will make the proper branch name and do the push:
bash dom/media/webrtc/third_party_build/push_official_branch.sh
122

edits