Details

• Time: 9:05 - 9:55 AM PT (17:05 - 17:55 UTC)
• Backchannel:
  • irc.mozilla.org #openwebapps
• Virtual Location:
  • "Mozilla Apps" Vidyo room
• 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
  • Gaia Automation - Includes Marketplace Automation
• Questions and Concerns
• Feedback Triage

P2/3 Other Projects

• Significant Updates
• Questions and Concerns

Minutes

Gaia Tests

• https://github.com/mozilla/gaia-ui-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