Media/WebRTC/Up-streaming Changes: Difference between revisions

From MozillaWiki
< Media‎ | WebRTC
Jump to navigation Jump to search
(Add pulling all heads info)
(Adding After The Code Is Landed Up-stream section)
Line 13: Line 13:
==Running Tests==
==Running Tests==
* While [https://www.chromium.org/developers/testing/running-tests/ these instructions] are for running Chromium tests, the same process applies for libwebrtc. There is no facility to help you run all the tests, you need to run all the test binaries that are produced. There are no facilities for helping you identify which tests you should be running. Inserting an RTC_CHECK(false), can be useful for verifying that one is testing using the correct binary.
* While [https://www.chromium.org/developers/testing/running-tests/ these instructions] are for running Chromium tests, the same process applies for libwebrtc. There is no facility to help you run all the tests, you need to run all the test binaries that are produced. There are no facilities for helping you identify which tests you should be running. Inserting an RTC_CHECK(false), can be useful for verifying that one is testing using the correct binary.
==Submitting Code==
==Code Submission Process==
==Opening An up-stream Bug==
===Writing A Unit Test===
* libwebrtc uses [http://webrtc-review.googlesource.com/ this Gerrit instance] to track bugs.
It is very likely that one will need to write a libwebrtc unit test that covers the code change, or alter a unit test to pass with the new code change. The unit test should ideally run correctly on both the main branch and the release branch that Firefox is using.
===Opening An up-stream Bug===
* libwebrtc uses [http://webrtc-review.googlesource.com/ this Gerrit instance] to track bugs. One will need to file a bug for one's fix under the appropriate component. In the bug one may mention that there is a fix that has been shipped in Firefox. Note the ID of the bug that Gerrit generated as one will need to use that ID in the commit message of your proposed fix.
===Submitting An up-stream Patch===
===Submitting An up-stream Patch===
===Requesting A Reviewer===
===Requesting A Reviewer===
===Asking For CI Runs===
===Asking For CI Runs===
 
===After The Code Is Landed Up-stream===
Now that the code is landed up-stream there are two more steps that one needs perform. Firstly, in the Mozilla repo one will create a backout patch for the code that was up-streamed. Secondly, one will create a cherry-pick patch from the upstream release.
==Tracking Progress==
==Tracking Progress==
There is a [https://docs.google.com/spreadsheets/d/1C9lg12ZQrctDU89zHB_bsni9pYTD7Ojos_7tq64Bjqs/edit#gid=0 spreadsheet] to track the progress of our in progress up-stream patches.
There is a [https://docs.google.com/spreadsheets/d/1C9lg12ZQrctDU89zHB_bsni9pYTD7Ojos_7tq64Bjqs/edit#gid=0 spreadsheet] to track the progress of our in progress up-stream patches.

Revision as of 19:22, 10 August 2023

Prerequisites

  • Install the prerequisite software for libwebrtc development as instructed here.
  • While that is installing create an account with the upstream repo. In order to submit patches as a Mozilla employee this will involve filling out a corporate contributor agreement via this bug. Also see the sections Contributing Your First Patch and Contributor Agreement for more information about the agreement itself.

One can check that one has been successfully added here. When you click "Manage your Agreements" at the bottom of the page should see that you have a Mozilla Corporate CLA listed. If you aren't already logged into a Google service, you will need to use Mozilla's SSO portal to log in to gmail or any other google product.

Installing Commit-Id Git Commit Hook Plugin

In order to push patch stacks (instead of squashing), one needs to have a Git commit hook installed to correlate the stack patches using a Change-Id.

  • To install the commit hook follow the instructions here.
  • The Change-Id Docs can be found here.

Checking Out The Source

  • Use the instructions here to checkout the upstream repo if you have not already. To get all of the branch heads one will need to alter the webrtc/src/.config file add the following line fetch = +refs/branch-heads/*:refs/remotes/branch-heads/* and run git pull. This is useful so that one can test out the patch against both master and the head of the release branch that is currently in use by Firefox.

Running Tests

  • While these instructions are for running Chromium tests, the same process applies for libwebrtc. There is no facility to help you run all the tests, you need to run all the test binaries that are produced. There are no facilities for helping you identify which tests you should be running. Inserting an RTC_CHECK(false), can be useful for verifying that one is testing using the correct binary.

Code Submission Process

Writing A Unit Test

It is very likely that one will need to write a libwebrtc unit test that covers the code change, or alter a unit test to pass with the new code change. The unit test should ideally run correctly on both the main branch and the release branch that Firefox is using.

Opening An up-stream Bug

  • libwebrtc uses this Gerrit instance to track bugs. One will need to file a bug for one's fix under the appropriate component. In the bug one may mention that there is a fix that has been shipped in Firefox. Note the ID of the bug that Gerrit generated as one will need to use that ID in the commit message of your proposed fix.

Submitting An up-stream Patch

Requesting A Reviewer

Asking For CI Runs

After The Code Is Landed Up-stream

Now that the code is landed up-stream there are two more steps that one needs perform. Firstly, in the Mozilla repo one will create a backout patch for the code that was up-streamed. Secondly, one will create a cherry-pick patch from the upstream release.

Tracking Progress

There is a spreadsheet to track the progress of our in progress up-stream patches.