Gaia/Meeting/2014-11-04

From MozillaWiki
Jump to: navigation, search

Weekly Gaia Development Meeting

Alternate Meeting Times:

  • "Early" meetings: Tues 9:00am SF, Wed 12:00am Taipei, Tues 6:00pm CET
  • "Late" meetings: Tues 6:00pm SF, Wed 9:00am Taipei

Announcements & Notices

Add your workweeks, new hires, other announcements:

Talk

   https://groups.google.com/d/topic/mozilla.dev.b2g/L_abPpFHXdM/discussion

Roundtable

  • Decoupling core apps from gaia.

Notes from Jonas re: decoupling: Technical steps:

  • Move a few APIs from certified to privileged.
  • Maybe create a privileged permission for "can use webcomponents"
  • Have the marketplace enable apps to put a "required gecko version"

in the app manifest, and then have the marketplace only serve such an app if the gecko version matches. This is very similar to how marketplace today enables apps to require support for certain APIs, so should be relatively easy to add.

  • Fix the client-side update code so that when we download an OS

update, that we also make sure to download updates for gecko-version-specific apps before restarting. Then apply app updates at the same time as we apply the OS update. These are mostly fairly easy to do. Only the last one is likely to be more work. That said, here is what I sent to David Scravaglieri on this topic: I think we need to have a bigger discussion about if it's a good idea to move apps to the marketplace before we do this. In the specific case of WebComponents we can easily solve the ability for a select few apps to have access to the API. That's one of the easier problems to solve. A much harder problem is that now the developers of those Gaia apps are expected to make their apps work on both the "old buggy" WebComponent implementation in (for example) 2.1, as well as the improved implementation in 2.2, as well as the amazing implementation in 2.3. Given that WebComponents are still under heavy development there might be significant differences between those three versions. And this is a bit of a general problem. Writing the Gaia apps such that they work across multiple versions of Gecko is much harder than making them work only in a single version. Especially since we're still heavily adding new features specifically for Gaia apps. Say that we add IndexedDB in Workers in 2.3. Does that mean that you won't use it there because then the same code wouldn't work on 2.2? I.e. would you be willing to have the email app for 2.3 be crappier than it could be in order to have the same code work on 2.2? Or would you ask developers to do runtime checks and run different code paths depending on if the app is running on 2.2 or 2.3? Is it better that we spend time on that than that we make the app be as good as it can be for 2.3? And how will we scale up QA? Are we now testing each app on multiple different versions of FirefoxOS? QA is already struggling badly with finding all the regressions as it is, multiplying their work load is not something I'm looking forward to. Discussion notes: [Jonas] What are we hoping to achieve? The reality is that we have very few users- those that we do have we can't push updates to The benefits seem small to me, but long term this could make sense Not talking about the technical cost or the platform work bc its small, but writing the gaia apps to work across multiple gecko version - to worry about that, is pretty significant Something we should take on- but when the benefit is higher than the cost Zibi- the additional cost for string freeze and l10n is going to be really high for us and the community Jonas- the release process would have multiple costly aspects- l10n, securtiy Kevin- my concern is the QA - we rely on our partners to catch our problems, so we would need to get quality much higher before considering doing that Jonas- make sure not to paint ourselves into a corner so that we can still do it in the future 3rd party devs can push updates on their own, so for us to do this technically isn't that hard The question is are there additional things we would want our own apps- like using experimental APIs With web components- it would just be enabled and we could use it everywhere We're building that infrastructure already James- 2 things If we don't start now then when do we start- are there things that we can get started on now? The other thing is whether other apps can use certified APIs, then that's an advantage. Think it would be fine to wait, but if we could try some steps in that direction- first would be to push localization updates through marketplace. Could make email priveledged- have the ability to download packs for priveledged apps. Sequence some way to the future- would also benefit other apps Jonas- on certified APIs, the reason we don't let people use them is only bc we don't want to let them- its bc of security- don't know a way to expose it without ensuring that 3rd parties won't steal users money. Not that we haven't figure out to expose it. If there are APIs, like Wifi, but people express interest, then its not as secure sensitive telephony. Its a process that's ongoing. Downloadable languages packs- sounds like something l10n is working on. Not sure if its a blocker for 3rd party developers. Agree that is sounds like a good thing to build, but orthoganal to what we do with our internal apps Zibi- localization API is not stable enough to offer it across multiple versions. Prefer to wait until we are a bit more stable James- whatever solution, we'll need a baseline range of gecko support no matter what. Jonas- agree with the desire to decouple- our platform should be stable enough to write cross version apps, but if you do this- it does mean that you have to limit the feature set vs if you just use the latest feature set. Makes our job of writing apps much harder. Same problem on Android- do I use the latest on L? or limit myself to APIs to version down to ics to get coverage across devices? If you have the ability, then can write multiple versions of apps. Its a very real cost. James- if we can start laying plumbing- if I want to scope to this release and higher- gecko/b2g version capabilities - seem like some things are possible Jonas- marketplace already have the ability to control what APIs to show based on availability - for them to add gecko version would be totally on mkplace side - that would be easy if they get requests The piece we might want to add is- I want to run on 38 or higher- I have only been tested on 38 and if user has gecko 40, then only show that app. I don't believe this is available. Aus- I've used that for building Android apps- I've just build different versions Ben- Android has probably suffered from not splitting out sooner- and with 6 month cadence, maybe we're happy with that, but we run the risk of not pushing our updates and also not pushing our updates at all (bc we rely on partners) By not turning our core gaia apps to priviledged -we're not seeing the pain of 3rd party apps. l10n, cross platform, etc. Are we getting too comfortable of certified APIs and not really fixing the platform problems? Jonas- there's a cost/ benefit problem. There are certain parts that we're not dogfooding- but imagine if we really got into the shoes of 3rd party developer and our apps really had to work cross platform, that would really be a high cost. Is it worth the cost of better understanding 3rd party? or can we get enough by just talking to them? Our default product, compared to Android, its not good enough- that needs to be our main focus (is selling devices). Getting 3rd party content has been easier than getting users. We should focus on good user experience. We're limited by the fact that the web is pretty bad in certain respects- that is our bigger 3rd party dev issue. James- that makes sense in terms of getting more users. If we could get the local bundles released and scoped per version- so don't have to worry about 2.1 l10n API is diff than 2.2- does that help with the get users goal? Sam- sounds like we need a roadmap. There's a mismatch between web as a platform and what Mozilla is focused on (getting handsets into the hands of people). Mozilla's vision- their goal is to move the web forward. The reality is that we can't affect the web unless we have a large user base. Jonas- I can share some of the visions that I have- but I shouldn't be the only one. Think everyone should be contributing towards that- the vision is definitely changing very often in response to various things that we learn Zibi- lack of market share- there are markets where we are starting to be relevant. We are getting into a position where we can push the market forward by introducing an APIs. Jonas- we can affect what people are building- but we can't affect what goes into web standards based on FxOS. more on desktop Zibi- I agree, but comparing us to other players because we aren't in all the markets they are in (US, etc). Jaime- questions: when is the right time? What are the triggers that will signal the right time?

QA

Reporter:

Support

Updates:

TEAM UPDATES

Productivity

Talking this week: Sprint tracking wiki: https://wiki.mozilla.org/FirefoxOS/productivity Notes: https://etherpad.mozilla.org/fxos-productivity The Team: asuth, evanxd, gaye, lightsofapollo, doliver, jrburke, mcav, millermedeiros, awiss, jhford, cserran, tony (qa), william hsu (qa), jhuang (ux), harly (ux) Updates:

Media front end

Talking this week: Our team: Dave Hylands, David Flanagan, Mike Habicher, Jim Porter, Hema Koka, Dominic Kuo, John Hu, Diego Marcos, Wilson Page, Justin D'Arcangelo , Punam Dahiya (part-time), Russ Nicoletti (part-time) Product: Sri Kasetti Ux: Rob MacDonald, Patryk Adamczyk EPM: Candice Serran QA: Marcia Knous Updates:

Comms app

Talking this week: Updates:

Systems front end

Talking this week: Sprint tracking wiki: https://wiki.mozilla.org/FirefoxOS/systemsfe Daily standups: https://etherpad.mozilla.org/fxos-systems-frontend2-0 The team: cserran, gwagner, qdot, michael h, aus, alexandre, francis, jason, pdol, benfrancis, daleharvey, gmarty, sfoster, naoki, tef, tedders1 Updates:

OPTIONAL UPDATES

System platform

RIL

Media recording

Device

Retrieved from "https://wiki.mozilla.org/index.php?title=Gaia/Meeting/2014-11-04&oldid=1031996"