And I think at least vosky provides OTA or FOTA himself. Explains why Ben sees
no updates :-).
dattaz a écrit :
FYI : Support of Nexus 4 and 5 should be keep.
People use it (http://ffos.vosky.fr/ ; nexus 5)
(https://yalam.co.uk/b2g/mako/ ; nexus 4) and the are need.
dattaz
Le 23/07/2015
On Thu, Jul 23, 2015 at 12:32 AM, Tim Guan-tin Chien timdr...@mozilla.com
wrote:
The one big exception here is the Browser API proxies. Sometimes
System app would need to access the Browser API methods exposed to
it's own embedder. Unless we implement some kind of
FYI : Support of Nexus 4 and 5 should be keep.
People use it (http://ffos.vosky.fr/ ; nexus 5)
(https://yalam.co.uk/b2g/mako/ ; nexus 4) and the are need.
dattaz
Le 23/07/2015 16:08, Shawn Huang a écrit :
I agree with Thomas, we still need to make sure gecko can survive across
different
We run regular builds in automation for the Nexus 4 and Nexus 5. Is anybody
still using these or can we safely turn them off? If we want them still, we
should probably get them running on Taskcluster at this point.
-Ryan
___
dev-b2g mailing list
I did an ad-hoc grep against the update server logs, and I see a total of zero
update requests for thees devices. That doesn't definitely mean that nobody
runs our builds, but it's pretty strong evidence.
On Thu, Jul 23, 2015 at 09:17:39AM -0400, Ryan VanderMeulen wrote:
We run regular builds
One of our topline goals for FxOS is is grow our foxfooder and contributor
base. To do that, we're looking at how we can support more people running
FxOS on existing Android hardware. We haven't mapped out a plan just yet,
but it might be useful to keep these alive for potential contributors.
On Fri, Jul 24, 2015 at 11:38 AM, Dietrich Ayala auton...@gmail.com wrote:
Immediately backout bad code. Immediately backout bad code.
Indeed. But that needs to be quickly followed by the relevant team
writing automated tests for the case that broke and was not caught in
automation.
- Kyle
Hi,
I stumbled upon a problem while developing apps on my foxfooding phone.
My app needs to access an API, which requires an API token (charges to my
account.) However, if I write it directly in the JS file, everybody can
easily see it by getting my package.zip or use a WebIDE console.
Is there
Maybe someone on the system app team can help. What requests are made out
of the box?
I've noticed the update service makes requests even when not configured to.
Bug is filed for that.
Any network requests that could be sim-triggered?
On Tue, Jul 21, 2015 at 12:19 AM Jovan Gerodetti
Immediately backout bad code. Immediately backout bad code.
On Thu, Jul 23, 2015 at 7:41 PM Naoki Hirata nhir...@mozilla.com wrote:
Currently our foxfood builds are blocked by two bugs. One gecko/one gaia:
https://wiki.mozilla.org/B2G/QA/Spark#Current_Versions
My question in regards to
Am 23.07.2015 um 16:03 schrieb Dale Harvey:
We cant distribute these builds to potential contributors, I dont see
much value in them being kept, I think maybe 2/3 people I know of used
them for a while and even they ended up running their own build server.
I see. Thanks for clarifying. In my
Hi
Am 23.07.2015 um 15:17 schrieb Ryan VanderMeulen:
We run regular builds in automation for the Nexus 4 and Nexus 5. Is
anybody still using these or can we safely turn them off? If we want
them still, we should probably get them running on Taskcluster at this
point.
I don't use my Nexus 4
I agree with Thomas, we still need to make sure gecko can survive across
different Android HAL API version.
I also heard that flame is going to be phased out and flaem-l is no longer
be supported, only z3c (aries-l) will be supported. Is it true? If it's
true, what's the proper device for
In regards to Flame-L, there is no official word about this as of yet. A
decision will be made soon.
On Thu, Jul 23, 2015 at 7:08 AM, Shawn Huang shu...@mozilla.com wrote:
I agree with Thomas, we still need to make sure gecko can survive across
different Android HAL API version.
I also
Sorry to jump in.
To my knowledge, bug work also needs Nexus-5(L) to do a cross-comparison
before Aries-L is ready.
Please think it over. Thanks!
Cheers,
William
-Original Message-
From: dev-b2g [mailto:dev-b2g-bounces+whsu=mozilla@lists.mozilla.org] On
Behalf Of Thomas Zimmermann
This is a general idea on our Device API evolution. I want to bring
this up and make sure it's a workable idea.
TLDR: Let's move mozChromeEvent to it's respective origin APIs and
expose them under |navigator.mozFoo.mgmt| with a special
|foo-manage-system| permission that we will only grant to
16 matches
Mail list logo
