On 8/13/14 11:21 AM, Ethan Hugg wrote:
I think there are definitely some concerns here.
>> 1. How we are going to handle updates on the plugin?
I'm not currently planning to update the plugin again for FF34 but it
could suddenly become necessary because of either a gmp-api change or
new bug found. The current process would be for me to create a bug
assigned to the build team with the commit ID of github/cisco/openh264
like this: https://bugzilla.mozilla.org/show_bug.cgi?id=1043416 The
build team would send me back the items to put on the CDN and update
the information on the update server. There should probably be a QA
pass between the CDN update and the update server changes somehow.
I'm glad we talk about this now :-)
Is there then a way to push the new binary to the CDN, but in an
in-active state (so not all browsers would automatically fetch it) so
that QA's can manually point there browser (or other test framework) at it?
My hope is that a QA could maybe modify the media.gmp-manager.url user
pref to point to such a new binary.
Also I'd like to point out that some of this code is missing automated
testing. It particular the code in openh264 that wraps it into a gmp
plugin (gmp-openh264.cpp). The basic encode/decode functionality is
tested with the CI of openh264 and Firefox has testing of GMP with a
fake plugin but this bit of code is in between.
Thanks for pointing that out. I think we are also completely missing any
automated test around the download of the plugin. That's what I'm
working on right now.
>> Do we plan to deploy updates regularly, or only on a per need base?
I'm only planning to update the plugin on a per-need basis. We don't
have outstanding crash/leak bugs on it and I don't think we need more
functionality so that mostly leaves reacting to changes in the API.
Sounds good.
Thanks
Nils Ohlmeier
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
