Media/WebRTC/libwebrtc Update Process Transition Plan
Before the new Media/WebRTC/libwebrtc_Update_Process can be executed, the existing copy of libwebrtc that exists in
media/webrtc/trunk needs to be modified such that it will be as if it has gone through the new process. This is being tracked by Bug 1654147.
Currently libwebrtc must be located inside of
media/webrtc/trunk, this must be made configurable such that code can be relocated. This is tracked by Bug 1654150.
We have a series of patches that remove unused files from libwebrtc, this speeds up the build and makes the executable smaller. In the new build process the files will be removed at the time that the library is vendored from Mozilla's Git repository. The vendoring script needs to be written, Bug 1654152, and we need to make sure that we have a minimal set of files.
After the build can be pointed at an out-of-tree copy of the library, it is likely that a number of paths will need to be fixed up. This is tracked by Bug 1654184.
Then it should be possible to collapse the path
dom/media/webrtc/*. Which will once again require numerous path changes, and is tracked by Bug 1654185. This can happen at any time, and the sooner it happens the better.
nICEr and SIPCC
nICEr and SIPCC can be moved into their own repositories, tracked here Bug 1654194 and here 1654188. Then they can be moved into
third_party, tracked here Bug 1654198 and here Bug 1654189. Doing all of this moving at once will cluster the Mercurial history changes together to avoid unwanted noise later.
Before the most recent WebRTC update it was possible to build the different sub directories of the
media folder from
mach. It would be extremely helpful to update process if we could get this back, as it would decouple building different sub components, such as
mediaconduit. One could get a component building before moving onto the next. This is being tracked by Bug 1654205.
Migrating libwebrtc to GitHub
There are a number of factors that make storing our soft fork of libwebrtc in Git appealing.
Our goal is to maintain as few, approaching zero, changes to the upstream version as possible. The upstream code is stored in a Git repository, so it makes it easier for us to upstream changes as we will no longer have to export patches. Likewise, it will make it easier to cherry pick patches from upstream.
By only removing files via the vendoring script, we will be able to more easily roll our version forward. As it is today, we will first need to undo all of our local deletions before we begin the merge process.
Creating The New Repository
The new repository needs to be created in GitHub, which is tracked by Bug 1654435.