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. 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. >> 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. -EH On Wed, Aug 13, 2014 at 9:38 AM, Nils Ohlmeier <[email protected]> wrote: > Hello, > > after the OpenH264 plugin is landed and usable now I started to wonder > > 1. How we are going to handle updates on the plugin? > 2. Do we need/want any monitoring of the download server and/or the > download success/failure rate? > > As development on OpenH264 seems to be pretty active I assume that we will > deploy/push updates at some point to our download server. > > * Do we plan to deploy updates regularly, or only on a per need base? > * How will we test such updates (as we don't have any automated tests > (I don't consider the fake plugin to give us any decent test > coverage here) I fear we are stuck with lots of manual testing here)? > > Even without deploying any updates of the plugin I'm concerned how do we > learn if something is broken for end users if anything is wrong on the > download server end. For example the server becomes unreachable, or the XML > can no longer be parsed, or... > My assumption here is no matter what goes wrong here the result will be > that a new user would end up with no H264 support on his browser. I'll > leave it to other people to judge how bad that would be. > I think it is pretty hard to predict how likely it is that we will run > into any kind of errors which results in plugin downloads not working. I > hope someone is monitoring the actual server. > > * But do we have for example telemetry data for success or failure > rate of the plugin (or how many times a browser re-tried before it > successfully downloaded the plugin)? > * If we don't have any or not enough visibility into download success > rates, is it worth investing into more monitoring or do we consider > the risk so low or the result not important enough to invest into > more monitoring? > > Maybe all of this has been taken care of and I'm just not aware of it. So > any feedback on this topic is welcome. > > Best Regards > Nils Ohlmeier > _______________________________________________ > dev-media mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-media > _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
