Closed ferjm closed 6 years ago
Ultimately, we should try to reduce the files in the core of the media stack that are glue'd. So MediaDecoder and MediaFormatReader should ideally not be in glue, but exact copies of upstream. The supporting code is less critical, but still important.
Spitballing a couple of ideas...
One strategy that we have used in the past for vendoring C libraries into Firefox was to maintain a stack of patches that we applied on top of the upstream code when we updated. The problem there is that patch
isn't as good at resolving conflicts as git or hg are. So it's not awesome.
What I sometimes do manually is when I update and get conflicts is I use a visual diff tool to compare what's changed in a specific file in m-c vs gecko-media. We could automate diffing I suppose, for example have the import script diff everything in glue with its source in m-c and compare with the previous diff (which would need to be committed) and warn if the diff changes significantly.
I might be missing something, but I believe that right now it's pretty easy to miss a bunch of changes in
gecko/glue
while updating from mozilla-central. As described in the README.md instructions, the process for updating the code ingecko/
is to runimport.py
to pull the changes from m-c, build and fix the potential build issues. But there are changes in m-c that may not trigger build errors and that we may be missing.For example: https://hg.mozilla.org/mozilla-central/rev/271a6b2de3ad . This patch modifies
MediaFormatReader.*
, but since these changes are self contained, missing them won't cause any build error. So we would be missing them and not applying them in our own modified version inglue/
.A initial step to help us update without missing changes could be to make the
import.py
script list the upstream commits (or bug #) since the last update affecting the files in thegecko/glue/
folder that were pulled from m-c.