7
edits
(Add an operational note on repo locking (REPO-elm)) |
(editorial: bullet lists) |
||
Line 3: | Line 3: | ||
== Operation Checklist == | == Operation Checklist == | ||
=== Prerequisites === | === 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. | |||
git clone https://github.com/mozilla/libwebrtc moz-libwebrtc | git clone https://github.com/mozilla/libwebrtc moz-libwebrtc | ||
hg clone --stream ssh://hg.mozilla.org/projects/elm | hg clone --stream ssh://hg.mozilla.org/projects/elm | ||
Line 31: | Line 30: | ||
=== Daily rebase on elm === | === 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. | |||
bash dom/media/webrtc/third_party_build/elm/elm_rebase.sh | bash dom/media/webrtc/third_party_build/elm/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. | |||
=== Post-merge Steps === | === 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 | 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. | |||
bash dom/media/webrtc/third_party_build/update_example_config.sh | bash dom/media/webrtc/third_party_build/update_example_config.sh | ||
* Follow the [[Media/WebRTC/libwebrtc_Update_Process#Resetting_Elm|Resetting_Elm]] steps below. | |||
=== Operational notes === | === 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} | 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} | 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). | |||
* 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 | 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. | |||
(cd {path-to}/moz-central && rm log_resume.txt) # resets the resume logic in loop-ff.sh | (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 && git rebase --abort) # don't finish this rebase | ||
(cd {path-to}/moz-libwebrtc/.. && tar czf moz-libwebrtc.tar.gz && cd moz-libwebrtc) | (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. | |||
* [[libwebrtc GYP generated Java files|GYP generated Java files]] | |||
== Resetting Elm == | == Resetting Elm == |
edits