Support for Nexus devices

[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.

-Ryan

[Ben Hearsum]

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.

[Peter Dolanjski]

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. 

Peter

_______________________________________________
dev-b2g mailing list
dev...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

[Thomas Zimmermann]

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 on a regular base, but I wouldn't like them to
slowly bit-rot.

* They are very easy to use for full-stack development, so contributors
might depend on them.

* I have a power harness for the Nexus 4.

* I occasionally use the Nexus 4 for testing JB compatibility.

If we ever want to deliver updates directly from Mozilla, we need a
strategy for testing all the older devices. I'd like to encourage the
creation of a set of legacy devices that consists of such older
hardware. Anything that is considered 'legacy' would get the full set of
automated tests with m-c on master once per week. This way we can spot
problems in a timely manner without overloading our test infrastructure.

Best regards
Thomas

[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.

There is work being done for builds that we can distribute (blob free) and hopefully we can get an active community around those and not see older devices bitrot

[Shawn Huang]

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 community developers to test with in the future?

--

Regards,

Shawn Huang

[Thomas Zimmermann]

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 answer I mixed up automated builds
and automated testing a bit. I always thought they somehow depend on
each other.

>
> There is work being done for builds that we can distribute (blob free)
> and hopefully we can get an active community around those and not see
> older devices bitrot
>
> On 23 July 2015 at 15:45, Thomas Zimmermann <tzimm...@mozilla.com

> > dev...@lists.mozilla.org <mailto:dev...@lists.mozilla.org>

> > https://lists.mozilla.org/listinfo/dev-b2g
>
> _______________________________________________
> dev-b2g mailing list

> dev...@lists.mozilla.org <mailto:dev...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-b2g
>
>

[Naoki Hirata]

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 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 community developers to test with in the future?

> https://lists.mozilla.org/listinfo/dev-b2g

_______________________________________________
dev-b2g mailing list

dev...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

--

Regards,

Shawn Huang

_______________________________________________
dev-b2g mailing list
dev...@lists.mozilla.org

https://lists.mozilla.org/listinfo/dev-b2g

[William Hsu]

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

[dattaz]

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 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 community developers to test with in the
> future?
>
> On 23 July 2015 at 21:45, Thomas Zimmermann <tzimm...@mozilla.com> wrote:
>

[Alexandre Lissy]

And I think at least vosky provides OTA or FOTA himself. Explains why Ben sees no updates :-).

dattaz a écrit :

--
Envoyé depuis Firefox OS

[Ryan VanderMeulen]

As a follow-up, it sounds like there is willingness to work on porting
the Nexus 4/5 builds on mozilla-central (master/v2.5) to Taskcluster. We
will wait to turn them off in buildbot until that happens.

With respect to v2.2, it is code complete now and receiving very little
in the way of new patches at this point, mostly the occasional security
patch. We still run emulator builds on that branch, which should be
sufficient to ensure that we don't accidentally break the builds. For
that reason, I intend to go ahead and turn the builds off on that branch
unless someone strongly objects.

-Ryan