Media/WebRTC/libwebrtc Update Process: Difference between revisions

Media/WebRTC/libwebrtc Update Process (view source)

Revision as of 22:43, 13 March 2023

11 bytes added , 13 March 2023

editorial: bullet lists

Pehrsons

7

edits

@@ Line 3: / Line 3: @@
 == Operation Checklist ==
 === 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.
+* 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.
-- 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.
   git clone https://github.com/mozilla/libwebrtc moz-libwebrtc
   hg clone --stream ssh://hg.mozilla.org/projects/elm
@@ Line 31: / Line 30: @@
 === Daily rebase on elm ===
-- Periodically, ideally daily to minimize surprises from mozilla-central, rebasing elm onto the latest mozilla-central is recommended.  Rebases should be completed until the request for merging elm to moz-central is made.
+Periodically, ideally daily to minimize surprises from mozilla-central, rebasing elm onto the latest mozilla-central is recommended.  Rebases should be completed until the request for merging elm to moz-central is made.
   bash dom/media/webrtc/third_party_build/elm/elm_rebase.sh
 === 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:
+* 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
+* Update the example config file for the next fast-forward operation.  This should be done in a separate bug, but if it has not been done prior, can be done at the beginning of the fast-forward operation as the first commit on elm.
-- Update the example config file for the next fast-forward operation.  This should be done in a separate bug, but if it has not been done prior, can be done at the beginning of the fast-forward operation as the first commit on elm.
   bash dom/media/webrtc/third_party_build/update_example_config.sh
+* Follow the [[Media/WebRTC/libwebrtc_Update_Process#Resetting_Elm|Resetting_Elm]] steps below.
-- Follow the [[Media/WebRTC/libwebrtc_Update_Process#Resetting_Elm|Resetting_Elm]] steps below.
 === 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>.
+* 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.
-- 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:
-- 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:
-- When making changes to fix Mozilla code in response to changes upstream, mercurial commit messages follow the pattern:
   Bug xxx (MOZ) - {description}
+* 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 REPO-elm in the first line of its description, i.e. the "title". The temporary commit allows loop-ff.sh to continue, whereas REPO-elm 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:
   tail -f ~/log-loop-ff.txt | grep loop-ff
+* If a particularly complicated rebase conflict is encountered, it is helpful to tar up the moz-libwebrtc directory to allow a complete reset without losing current progress.
-- If a particularly complicated rebase conflict is encountered, it is helpful to tar up the moz-libwebrtc directory to allow a complete reset without losing current progress.
   (cd {path-to}/moz-central && rm log_resume.txt) # resets the resume logic in loop-ff.sh
   (cd {path-to}/moz-libwebrtc && git rebase --abort) # don't finish this rebase
   (cd {path-to}/moz-libwebrtc/.. && tar czf moz-libwebrtc.tar.gz && cd moz-libwebrtc)
+* Stopping the loop-ff.sh manually is best done when in the <code>Test build</code> phase using Ctrl-c.
-- Stopping the loop-ff.sh manually is best done when in the <code>Test build</code> phase using Ctrl-c.
+* [[libwebrtc GYP generated Java files|GYP generated Java files]]
-- [[libwebrtc GYP generated Java files|GYP generated Java files]]
 == Resetting Elm ==