Apps/StatusMeetings/Engineering/2012-11-28
From MozillaWiki
< Apps | StatusMeetings | Engineering
Contents
Details
- Time: 9:05 - 9:55 AM PT (17:05 - 17:55 UTC)
- Backchannel:
- Virtual Location:
- Physical Locations:
- Mountain View: 3Z - Zombocom
- San Francisco: 324 - Bay Bridge
- Audio-only Access:
- +1-650-903-0800 or +1-650-215-1282, x92, conf#: 98652 (US/INTL)
- +1-800-707-2533, pin: 369, conf#: 98652 (US toll free)
- etherpad for taking minutes
Agenda
P1 Firefox OS Basecamp
- Significant Updates
- Questions and Concerns
- Feedback Triage
P2/3 Other Projects
- Significant Updates
- Questions and Concerns
Minutes
Gaia Tests
Pre-installed Apps
- identifying apps and getting them through pipelines is high-risk at the moment
- brazil is top priority
- moving forward with first 3 countries
- mexico wants to go in may/june timeframe; unclear if we can achieve that - no formal change announcement/request received from Telefonica to date.
- all markets want to launch in latter half of Q2, may/june
- january 15 is drop-dead code freeze deadline for all these
- Please see https://wiki.mozilla.org/Apps/StatusMeetings/ContentProgram/Content_Types_for_Dummies for information on content types & categories used to discuss pre-installed apps.
- Pre-installed apps has a critical dependency on the ability to sign packaged apps. How soon will it land? (Server side ready now. client side not yet up).
Payments
- User Stories & Target Dates for Milestones: https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AqMmxHRazC75dDAyVjdBM2gwUWlzLUR2S3Y1b0RIdHc#gid=5
- five countries in scope, in contract with vendor
- additional countries not in scope, require changes to contract
- start with country 1, where bluevia integrated with bango
- additional countries would happen one at a time
- december 15 "get ready for testing" milestone for some user stories
- other user stories will be delivered over the following months
- user stories will be delivered all the way up to the may/june timeframe
- payments rollout may be different from firefox os rollout
- automated refunds out of scope for version one
- there will be a refund process, it'll be largely manual
- it'll be initiated by mozilla marketplace
- each country has its own special set of taxes, fees, etc.
- the marketplace is responsible for that, payment processors are not
Android Payments
- dbialer going to start specifying
- will be in google doc, should be ready next week
OOP Packaged Apps
- busted
- bug 813468: https://bugzilla.mozilla.org/show_bug.cgi?id=813468
- patch from fabrice
- -> myk to follow up with fabrice on the status of bug 813468
- app install bug: https://bugzilla.mozilla.org/show_bug.cgi?id=802574
Signing Capabilities for Packaged Apps
- timeline? pre-installed apps depends on it
- server is up, ready, successfully signs apps
- can't find privileged API that is actually checked on device
- contacts API should be doing that
- we are successfully signing and verifying packages on the client
- jsmith sent sample app to bsmith and rtilder last night
- client part for signing is not yet landed
- packaged app team has daily standup at 11:30
- -> caitlin to get update and report back on status of signing for packaged apps
Apps For Android
- new developer James Hugman - Welcome !
- see payments update above
- wesj and mfinkle bugs to be reassigned to jhugman - timing tbd
- elancaster to project manage for now until assignments shift
- dbialer working on Android user stories for payments / privileged & packaged apps
Signing and Operators
- is our signing method acceptable for operators?
- we're mostly talking about signing of third-party apps
- haven't heard about concerns from partners
- partners tend to be concerned about signing of main software on device: kernel, gecko, core apps
- there are ongoing discussions about who signs what, who owns the bits on the device
- bmoss can answer questions or direct you to someone who does (cjones?)
- it's a different type of signing
- dbialer mostly concerned about signing of third-party apps and authentication of developer
- kward: based on previous experience, carrier security departments tend to be particular about this
- don't want carriers to raise flags at late date where it becomes a launch blocker
- bwalker is going to give it some thought and figure out best way to approach
- sicking wants to be involved in any discussions with carriers
- on android developers are expected to sign everything
- developers use self-signed certificates that they generate themselves
- apple generates certs on their developers' behalves
- on android, cert links apps together (update guaranteed to be from same developer who wrote original); doesn't actually authenticate
- no plan for developer signing for 1.0
- signing is just proof that we've reviewed and approved the app
Actions
- myk to follow up with fabrice on the status of bug 813468
- caitlin to get update and report back on status of signing for packaged apps