(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
>> 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
> 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
> 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 . 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.
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
Actually I worked on a few keyboard patches of my own with
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
3. When Mulet is ready and when our testing bots have switched to use
Mulet, change the above documentation/script from B2G Desktop to
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?