Propose to drop Run-Gaia-in-Firefox-Nightly support, and switch to B2G Desktop

[Tim Chien]

Hi all,

:gerv complained to me sometime ago on IRC that he can't get Gaia to
work following

https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/Running_the_Gaia_codebase#Running_Gaia_in_Desktop_Firefox

and only to realize this was broken for quite some time after
confirming with people on IRC. Imagine frustration of any other
community hackers out there.

It's not a surprise that Fx Nightly support remain broken and no one
is fixing it. MoCo/partner developers generally have devices at hand
so we almost always use Phone + App Manager/WebIDE. The Nightly
environment was not protected by CI either, so no one will hear about
it when it breaks.

Still we need something offers to the world for people to hack Gaia
without the phone. I propose we switch to B2G Desktop cause that's
what currently our integration tests depend on, so it can't break (or,
it will get fixed and remain working as long as tree is open). I
however don't know how to make App Manager/WebIDE connects to B2G
Desktop, so this need further investigation.

I won't object if something like Mulet run out to be a better option,
provided that the setup is protected on CI. If there is an option for
FxOS Simulator to "Use my own profile" that would be excellent too.

Feedback welcome,

--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)

[Tim Chien]

Alex,

I am interested to know what's extra for Mulet, beside for Mulet itself.

So Mulet will be a replacement of B2G Desktop, so that means Gij Gip
will be migrate there right? That would make Mulet fits my requirement
of "protected under CI" if these CI profiles are exactly the same as
we offered to the developers (i.e. no separate Mock APIs will be
maintained separately).

Also, use Mulet over Nightly still means we will be giving up F5
right? How do you feel about the feasibility of implementing
livereload for package apps?


On Thu, Oct 23, 2014 at 9:21 PM, Yura Zenevich <yzen...@mozilla.com> wrote:
>
> On 2014-10-23, 6:03 AM, Alexandre poirot wrote:
>
> Gaia in Fx nightly is going to be deprecated in favor of Mulet.
> But unfortunately, Fx nightly support has been broken for ages and Mulet
> isn't here yet.
> Most gaia contributors seem to be only working on devices now.
> I hear only very few developers using desktop runtimes, except for tests.
>
> I think this is a much bigger problem when we think of attracting new
> contributors. Asking for a device is too much of a commitment and expense.
> Many of the good first bugs that I am trying to mentor are stuck at "Sorry
> you can't run Gaia with Firefox for Desktop ATM." It feels like an
> impassible barrier to entry.
>
> That may be because of the Nightly breakages. In the early days of FxOS,
> most gaia developers were using it intensively...
>
> I hope that Mulet is going to bring back some more usage of the desktop
> runtime.
> Mostly because it will be better than b2g desktop and way more stable than
> the Fx nightly hack.
> Today, it is possible to use a custom b2g desktop with WebIDE, but it is
> unecessary complex.
> You have to play with settings, magic command line arguments and multiple
> windows.
> I think that's what Kevin said about Fx nightly/Mulet being better than b2g
> desktop.
> The main reason is that devtools are built-in! In the same window, with
> absolutely no magic, nor any complex setup.
> And you have F5...
>
> So I wish Mulet was already here and we could deprecate Fx nightly in favor
> of Mulet.
> Actually it is almost ready. We just got a regression (bug 1082001) that
> prevents me from announcing its official release.
> We already have Mulet nightlies and it is already tested on TBPL.
> I hope it will be a matter of days now before Gaia developers can start
> testing it.
> Then it will take some more time before it can become the reference runtime
> on desktop.
>
> Alexandre, I noticed, when playing with Mulet, that one dev addon in
> particular, was missing from the dev tools panel - the screen reader
> simulator. It was originally present in the dev tools panel in Gaia profile
> for Firefox Desktop and was packaged as an external addon there. Would
> something similar need to happen for Mulet as well, to have it included?
>
>
> At the end I have a mixed feeling about pushing hard on documenting b2g
> desktop.
> Fx nightly mode and Mulet are extremelly similar in term of usage and
> documentation.
> Hopefully we can just promote Mulet and tweak the existing Fx nightly docs.
>
>
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia

[Alexandre poirot]

2014-10-24 8:35 GMT+02:00 Tim Chien <timd...@mozilla.com>:

So Mulet will be a replacement of B2G Desktop, so that means Gij Gip
will be migrate there right?

That's the goal. Mulet will hopefully become the reference platform to run gaia on desktop.

Simulator addons are going to switch from b2g-desktop to mulet,
and hopefully, we can deprecate b2g desktop once mulet is fully ready.

Then, on CI, mulet should become the reference platform to look for tests being green or not!

(as of today, we still run only gecko test against mulet, for work is ongoing to start running all gaia tests)

That would make Mulet fits my requirement
of "protected under CI" if these CI profiles are exactly the same as
we offered to the developers (i.e. no separate Mock APIs will be
maintained separately).

Yes! That's the whole point of mulet. Have a supported "Fx nightly thing".

And the main difference between Fx nightly and mulet is that we have all b2g specifics turned on!

So no mock, or at least not more than we currently have for *b2g desktop*.

(we still need some mock on b2g-desktop as not all API are functional on desktop)

i.e. all APIs that currently work on b2g-desktop are working in mulet.

Also, use Mulet over Nightly still means we will be giving up F5
right?

 

No, it works with both DEBUG and non-DEBUG profiles.

So that you can develop with both kinds.

It has no effect on using mocks or not, it just depends on the httpd hack.

And now that this hack uses app:// protocol, it is quite transparent.

How do you feel about the feasibility of implementing
livereload for package apps?

livereload challenges are all about the build system, it doesn't depend much on using the mulet/nightly or not.

The current httpd hacks is quite good, but we still need to find a way to rebuild the app on F5...

We may finally have incremental build working again, it may help to provide such feature.

If that's something you consider important, I can mentor Ricky on that subject,

but only once build system performances are rocking fast!

[Gabriele Svelto]

On 24/10/2014 11:40, Alexandre poirot wrote:
> That's the goal. Mulet will hopefully become the reference platform to
> run gaia on desktop.
> Simulator addons are going to switch from b2g-desktop to mulet,
> and hopefully, we can deprecate b2g desktop once mulet is fully ready.

It sounds to me that after mulet becomes usable we'll have quite a bit
of nightly- and b2g-desktop-specific code left behind to rot in the
codebase. Are there plans to rip out everything that's not needed once
we deprecate both nightly and b2g-desktop for use with gaia?

Gabriele

[Tim Chien]

(updated proposal below)

Yeah, sorry for not being clear, but I was meant to deprecate DEBUG=1
profile building as well once we drop Nightly support.

DEBUG=1 profile runs app with their source code, not the built result,
which reflect the actual device runtime less (and hence the livereload
idea to replace it)

Obviously since our unit test environment still depend on it, we can't
remove it at once when we drop the Nightly support.

On Fri, Oct 24, 2014 at 5:40 PM, Alexandre poirot <poiro...@gmail.com> wrote:
>> How do you feel about the feasibility of implementing
>> livereload for package apps?
>
> livereload challenges are all about the build system, it doesn't depend much
> on using the mulet/nightly or not.
> The current httpd hacks is quite good, but we still need to find a way to
> rebuild the app on F5...
> We may finally have incremental build working again, it may help to provide
> such feature.
> If that's something you consider important, I can mentor Ricky on that
> subject,
> but only once build system performances are rocking fast!
>

Understood. One thing to clarify is that incremental build never
worked, but having parallel build was. Parallel build is indeed
Ricky's next top issue, and certainly he could work on incremental
build if that's the prerequisite of having livereload support.

On Fri, Oct 24, 2014 at 5:53 PM, Julien Wajsberg <jwaj...@mozilla.com> wrote:
> It's _not_ the same for apps where developers don't work this way. It's ok.
>
> I think we're now in a moment where all teams can't work in the same
> way. It's simply not efficient, and we can see that it's not happening.
> Every team work in a particular way, and that's fine. Now, every team
> needs to do a good job on documenting this. In the SMS app, I started a
> README file to explain how to work with this app [1]. I think it would
> be a good practice to have this in every app. Maybe in some apps it
> would just be a link to MDN and how to run in B2G Desktop. Other apps
> would have different instructions.
>
> [1]
> https://github.com/julienw/gaia/blob/1082618-sms-readme/apps/sms/README.md
>
> --
> Julien
>

Totally agree. I am not forcing you to give up your work flow -- I
merely want to point out Nightly no longer work for Gaia _in general_
and we should not support it anymore _in general_. We should
definitely figure out a substitute workflow for your use case before
removing anything.

Actually I worked on a few keyboard patches of my own with
http://timdream.org/gaia-keyboard-demo/
and I even had fun testing keyboard multi-touch behavior with an iPhone. :)
That's definitely not a workflow adoptable for other apps.

===

I think we have a clear picture on how things should work. Here is my
refined proposal, step-by-step:

1. We should change the MDN documentation pointing people to use B2G
Desktop *now*, with clear documentation on download, set-up, and
remote debugging with App Manager/WebIDE.
1.1. Documentation adove can point out app-specific work flow,
including mentioning of Nightly support before (5) happens.
2. We should look at the above steps and attempt to simplify the
tooling, for example, create a |make run| target to do everything
automatically.
3. When Mulet is ready and when our testing bots have switched to use
Mulet, change the above documentation/script from B2G Desktop to
Mulet.
4. Implement a livereload extension for package apps after other
depending build script works, to replace F5 workflow.
5. Once F5 workflow and unit test use case are fulfilled, remove the
DEBUG=1 profile support and httpd hack.

Does this sounds a good proposal which everyone agrees?

[Chris Mills]

Yes, I entirely agree Tim. But I am having difficulty with the Desktop B2G/WebIDE workflow. The current steps I am using are:

1. Install latest Desktop B2G nightly from https://nightly.mozilla.org/
2. Install latest Desktop Firefox nightly from https://nightly.mozilla.org/
3. Fork https://github.com/mozilla-b2g/gaia
4. Clone your Gaia fork locally
5. cd into your local Gaia directory and build a debug profile with DEBUG=1 make
6. Run your Gaia profile inside Desktop B2G with the following command (example comes from Mac, and was run from inside the Applications folder, but we could include other OSes too):
./B2G.app/Contents/MacOS/b2g-bin -profile path/to/your/profile-debug
7. Open Firefox desktop nightly, open Web IDE (Tools > Web Developer > WebIDE)
8. In WebIDE, select Choose runtime > Remote Runtime
9. make sure it says localhost:6000 in the box and press ok
10. Now you should be connected to your Gaia profile running in Desktop B2G, from WebIDE!

Problems:

1. When I try to load one of my packaged apps into my Desktop B2G instance, it installs the app, but then no content is shown when opening the app at all.
2. I can’t seem to debug certified/system apps running in Desktop B2G via WebIDE - it doesn’t list them, and I can’t request higher privileges (Runtime > Runtime Info > Request higher privileges). That option doesn’t seem to work.

> 1.1. Documentation adove can point out app-specific work flow,
> including mentioning of Nightly support before (5) happens.
> 2. We should look at the above steps and attempt to simplify the
> tooling, for example, create a |make run| target to do everything
> automatically.
> 3. When Mulet is ready and when our testing bots have switched to use
> Mulet, change the above documentation/script from B2G Desktop to
> Mulet.
> 4. Implement a livereload extension for package apps after other
> depending build script works, to replace F5 workflow.
> 5. Once F5 workflow and unit test use case are fulfilled, remove the
> DEBUG=1 profile support and httpd hack.
>
> Does this sounds a good proposal which everyone agrees?
>
> --
> Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
> OS, Mozilla Corp. (Taiwan)

[J. Ryan Stinnett]

On Sat, Oct 25, 2014 at 2:35 AM, Chris Mills <cmi...@mozilla.com> wrote:
> 2. I can’t seem to debug certified/system apps running in Desktop B2G via WebIDE - it doesn’t list them, and I can’t request higher privileges (Runtime > Runtime Info > Request higher privileges). That option doesn’t seem to work.

You would need to manually set the pref to allow certified debugging
in your Gaia profile. You could choose to do this with a custom Gaia
pref file[1].

Check the prefs and settings that the Simulator add-on applies to its
Gaia profile[2] for reference.

WebIDE's "request higher privileges" button currently assumes it's
connected to real device over ADB, so that's why it fails here.

[1]: https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/Build_System_Primer#Customizing_the_preferences
[2]: http://dxr.mozilla.org/mozilla-central/source/b2g/simulator

- Ryan

[Chris Mills]

Ryan, you are a superstar. So after creating a custom-prefs.js inside build/config, and giving it the line

user_pref("devtools.debugger.forbid-certified-apps", false);

I then built my debug build, ran it inside Desktop B2G, set that as the WebIDE runtime, and now I can debug the gaia apps from my custom profile in webIDE.

HOWEVER, there is still a problem. When I try to run apps so I can see the effect of my code changes, they won’t run. I just get an “Operation timed out” message. I really have no idea why this is.

Chris Mills
Senior tech writer || Mozilla
developer.mozilla.org || MDN
cmi...@mozilla.com || @chrisdavidmills

[Julien Wajsberg]

Le 24/10/2014 16:54, Tim Chien a écrit :
> (updated proposal below)

>
>
> I think we have a clear picture on how things should work. Here is my
> refined proposal, step-by-step:
>
> 1. We should change the MDN documentation pointing people to use B2G
> Desktop *now*, with clear documentation on download, set-up, and
> remote debugging with App Manager/WebIDE.

> 1.1. Documentation adove can point out app-specific work flow,
> including mentioning of Nightly support before (5) happens.
> 2. We should look at the above steps and attempt to simplify the
> tooling, for example, create a |make run| target to do everything
> automatically.
> 3. When Mulet is ready and when our testing bots have switched to use
> Mulet, change the above documentation/script from B2G Desktop to
> Mulet.
> 4. Implement a livereload extension for package apps after other
> depending build script works, to replace F5 workflow.
> 5. Once F5 workflow and unit test use case are fulfilled, remove the
> DEBUG=1 profile support and httpd hack.
>
> Does this sounds a good proposal which everyone agrees?
>

That sounds a lot of work, for a not so clear improvement over the
current situation. (I'm assuming we're in a short-term future where we
use Mulet instead of B2G Desktop or Nightly).

If the issue you're trying to solve is "the development environment is
not tested in TBPL", then I think testing using Mulet instead of B2G
Desktop + running unit tests in Mulet will cover this pretty well.

Which other issue are you trying to solve here?

I agree that using httpd.js is a dirty hack, but it works well enough,
and doing it differently would take a lot of work. I think the resource
could be better employed.

Here is my wishlist for improving the build system:

* I want a parallelized build system so that it does not take 51sec to
make an unoptimized profile, and 3m37sec to make an optimized profile
with -j4. This was started by Yuren before he left Mozilla but was never
resumed.
* I don't want to redownload modules.tar whenever I switch to a branch
that doesn't depend on the same hash (like I did back at the time for
XULRunner, and is still used for b2g_sdk fortunately)
* I don't want to run the build for all apps when all I want is install
my own app to the device

These 3 points would improve my daily work _a lot_. Removing httpd.js
and DEBUG=1 profile won't.
I'm waiting for points 1 and 3 since I started working on the project 2
years ago. I probably should have filed bugs for these, but I sadly
assumed these goals were obvious.

So, Tim, I'm sorry I have to disagree with your proposal.

Regards,
--
Julien

[gd...@mozilla.com]

>
> * I want a parallelized build system so that it does not take 51sec to
> make an unoptimized profile, and 3m37sec to make an optimized profile
> with -j4. This was started by Yuren before he left Mozilla but was never
> resumed.

Ricky is handling paralleling build here.
https://bugzilla.mozilla.org/show_bug.cgi?id=1070442

> * I don't want to run the build for all apps when all I want is install
> my own app to the device

I think this bug is what you're talking about. We're in progress.
https://bugzilla.mozilla.org/show_bug.cgi?id=969215

[Tim Chien]

Another issue I am trying to solve is the complexity of the build code
base to support httpd.js hack (and DEBUG=1 build).
And sorry for not being clear about it.

> Here is my wishlist for improving the build system:
>

> * I want a parallelized build system so that it does not take 51sec to
> make an unoptimized profile, and 3m37sec to make an optimized profile
> with -j4. This was started by Yuren before he left Mozilla but was never
> resumed.

> * I don't want to redownload modules.tar whenever I switch to a branch
> that doesn't depend on the same hash (like I did back at the time for
> XULRunner, and is still used for b2g_sdk fortunately)

> * I don't want to run the build for all apps when all I want is install
> my own app to the device
>

> These 3 points would improve my daily work _a lot_. Removing httpd.js
> and DEBUG=1 profile won't.
> I'm waiting for points 1 and 3 since I started working on the project 2
> years ago. I probably should have filed bugs for these, but I sadly
> assumed these goals were obvious.
>
> So, Tim, I'm sorry I have to disagree with your proposal.
>
> Regards,
> --
> Julien
>

Fine.

The ultimate goal of Gaia/Gaia build is to serve developers, and I
agree with you you are making valid points on your wish list.
I don't see any objection from you (nor James) on point 1/1.1/2 so I
assume you are not objecting to these, and they don't pose significant
workload either. Therefore, if there are no questions specifically on
this part, I will ask people to go ahead and implement it.

As of 3/4/5 we can resume the conversation once we have the wishlist done.
(Actually these work was included as "dependencies" described in point
4 when I wrote that e-mail, but anyway I should take the blame for not
saying that explicitly)

Do I understand you correctly? Is this something we could agree on?

Thanks,

[Julien Wajsberg]

The fact is that I really fail to see what is complex about it in the build.
DEBUG=1 is only setting some different prefs and copying extensions.

What is quite complex is httpd.js itself, that, I can agree, especially
regarding the localization part.

Yep, no objection on this.

>
> As of 3/4/5 we can resume the conversation once we have the wishlist done.
> (Actually these work was included as "dependencies" described in point
> 4 when I wrote that e-mail, but anyway I should take the blame for not
> saying that explicitly)

Note it was only my opinion here, of course I also value the opnions of
the build owners and whatever they think is useful to keep the build
sane in the long term.

--
Julien