Re: Intent to implement: navigator.deviceStorage
Hi all, The purpose of this topic is to implement navigator.deviceStorage. Since Ehsan agreed with this proposal already, may I close this session? The reason is 1. We didn't decide the resource and detail yet so I suggest to discuss it back to dev-webapi. And after we finalize the spec and resource, will notice dev-platform for concrete plan and date/release. 2. About virtual device storage, will discuss it in dev-webapi as well and back to dev-platform when we are going to implement it. Hi Dave and Ehsan, May I know your suggestion? Thanks, Sincerely yours. - 原始郵件 - 寄件者: Ehsan Akhgari ehsan.akhg...@gmail.com 收件者: Marco Chen mc...@mozilla.com 副本: dev-platform@lists.mozilla.org 寄件備份: 2014 7 月 22 星期二 上午 2:01:13 主旨: Re: Intent to implement: navigator.deviceStorage Yes, indeed. Below, I meant to agree with adding a new EventTarget where these events can be targeted to. :-) Cheers, Ehsan On 2014-07-21, 12:05 PM, Marco Chen wrote: Yes, I agree with you for virtual device storage API. But before discussing the detail of virutal device storage api, the first step here is to figure out where should new event handler be added? Since there is not only new event handler been added but also a set of APIs potentially, I support to Dave' suggestion. *寄件者: *Ehsan Akhgari ehsan.akhg...@gmail.com *收件者: *mc...@mozilla.com, dev-platform@lists.mozilla.org *寄件備份: *2014 7 月 21 星期一 下午 11:32:33 *主旨: *Re: Intent to implement: navigator.deviceStorage On 2014-07-20, 10:43 PM, mc...@mozilla.com wrote: Perhaps adding an EventListener on Window would be enough, so that we can keep the same API? As Dave said, we might still need to propose a set of WebAPI for Virutal Device Storage (Then we can have apps like dropboxstorage app, googledriverstorage app and sambaStorage app). If we can add navigator.deviceStorage then these old and new proposed APIs can be put together. (not sure this is a principle of designing Web API or we can split functions/events to different places). That sounds good, but of course we need a more concrete proposal for the virtual device storage API. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: navigator.deviceStorage
On 2014-07-22, 11:10 AM, Marco Chen wrote: Hi all, The purpose of this topic is to implement navigator.deviceStorage. Since Ehsan agreed with this proposal already, may I close this session? We still don't have a proposal yet, do we? It's fine to discuss this on dev-webapi too, but the discussion is not done yet. :-) Cheers, Ehsan The reason is 1. We didn't decide the resource and detail yet so I suggest to discuss it back to dev-webapi. And after we finalize the spec and resource, will notice dev-platform for concrete plan and date/release. 2. About virtual device storage, will discuss it in dev-webapi as well and back to dev-platform when we are going to implement it. Hi Dave and Ehsan, May I know your suggestion? Thanks, Sincerely yours. *寄件者: *Ehsan Akhgari ehsan.akhg...@gmail.com *收件者: *Marco Chen mc...@mozilla.com *副本: *dev-platform@lists.mozilla.org *寄件備份: *2014 7 月 22 星期二 上午 2:01:13 *主旨: *Re: Intent to implement: navigator.deviceStorage Yes, indeed. Below, I meant to agree with adding a new EventTarget where these events can be targeted to. :-) Cheers, Ehsan On 2014-07-21, 12:05 PM, Marco Chen wrote: Yes, I agree with you for virtual device storage API. But before discussing the detail of virutal device storage api, the first step here is to figure out where should new event handler be added? Since there is not only new event handler been added but also a set of APIs potentially, I support to Dave' suggestion. *寄件者: *Ehsan Akhgari ehsan.akhg...@gmail.com *收件者: *mc...@mozilla.com, dev-platform@lists.mozilla.org *寄件備份: *2014 7 月 21 星期一 下午 11:32:33 *主旨: *Re: Intent to implement: navigator.deviceStorage On 2014-07-20, 10:43 PM, mc...@mozilla.com wrote: Perhaps adding an EventListener on Window would be enough, so that we can keep the same API? As Dave said, we might still need to propose a set of WebAPI for Virutal Device Storage (Then we can have apps like dropboxstorage app, googledriverstorage app and sambaStorage app). If we can add navigator.deviceStorage then these old and new proposed APIs can be put together. (not sure this is a principle of designing Web API or we can split functions/events to different places). That sounds good, but of course we need a more concrete proposal for the virtual device storage API. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deploy: plugin timeout A/B test experiment, bug 1018200
I missed this earlier. Lacking any major concerns (Jet did express one), I approve the deployment of this experiment on Beta 32 on behalf of release management. Lawrence - Original Message - This is an official notice of intent to deploy the experiment in bug 1018200 to the beta channel. The experiment is an A/B test to determine the optimal value of the dom.ipc.plugins.unloadTimeoutSecs on the FF32 beta. This setting determines primarily how long we wait to unload Flash and other plugins after a user isn't using it any more while browsing. Users in the experiment will be grouped into 8 equal groups whose timeouts will be set to various values: 0, 5, 15, 30, 60, 90, 120, and 300 seconds. The experiment parameters are: MinVersion: 32.0 MaxVersion: 34.* Start Date: 01-Jul-2014 End Date: 02-Sep-2014 Maximum runtime: 42.0 days Update Channels: beta Sample Rate: 5% Low-priority experiment: this experiment is lower-priority than the translation experiment already scheduled for beta, so any users eligible for that experiment will participate in that one first. A reminder that the experiment system only runs one experiment at a time, so there is no chance of multiple experiments conflicting. To analyze the results I intend after 2-3 weeks to correlate the experiment groups against the telemetry measurement for plugin launch time (bug 1011136). This will tell us both how often users are launching plugins, but also how long those plugin launches take. My intent is to pick a final value for this preference based on the data before we ship FF32 to release. Chad, I'm looking for your approval to use 5% of the beta population for this experiment. Release-drivers, I am looking for your approval to enable this experiment as soon as Kamil completes QA verification on staging. gps, I would like you to take care of getting this experiment deployed to production when everything is ready and monitoring the deployment, since I will be on vacation. I want to thank Qeole, a contributor who implemented the correct timeout setting, the telemetry probe, and this experiment all himself. He/she has done this thoughtfully and well. --BDS ___ release-drivers mailing list release-driv...@mozilla.org https://mail.mozilla.org/listinfo/release-drivers ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fopen, gtest and try
Another use case here is we want to write GTests to test Gecko Media Plugins. These are the plugins we're using for EME and OpenH264 plugins. To load them we need to set an environment variable to the path of the directory in which the plugin dll resides, or pass that path to the plugin to a function. Currently we haven't figured out how to do this, for all reasons you outlined already. Chris P. On 7/11/2014 12:06 AM, Ted Mielczarek wrote: On Thu, Jul 10, 2014, at 12:17 AM, Anthony Jones wrote: I've recently been using gtest for media code. However I've come across the issue of fopen() working locally but not on the try servers. https://tbpl.mozilla.org/?tree=Tryrev=11d9f94c54bd Any suggestions on how I should do this differently? I'm guessing this is a working directory issue. On Try gtest will be running as part of make check, so the cwd will be $objdir/testing/gtest: http://hg.mozilla.org/mozilla-central/annotate/cb75d6cfb004/testing/gtest/Makefile.in#l24 Whereas if you're doing mach gtest it looks like it doesn't change the cwd so it'll be $topsrcdir: http://hg.mozilla.org/mozilla-central/annotate/cb75d6cfb004/python/mozbuild/mozbuild/mach_commands.py#l616 If you run ./mach build testing/gtest/check do you get the same failures locally? We should make these consistent to avoid this problem. However, note that relying on external files is going to cause issues in the future, we should figure out exactly what we want here--we're going to eventually move gtest out of make check and into the test package, which means that we'd have to explicitly copy files that tests want to reference. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Transition from TBPL to Treeherder
On 7/22/2014 8:01 PM, Jonathan Eads wrote: We’ve got lots of plans for useful bells and whistles in future releases, but the first step is reaching full feature parity with TBPL. We need to make sure sheriffs and developers can carry out business as usual. I'd love to play with it for my uses, but bug 1035222 makes it impossible for me to use it and potentially find even more bugs. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
