From MozillaWiki
Jump to: navigation, search


Background: Native UI will land in phones about Fennec 11 and tablets in 13 or 14. These crashes will have the same product name, but they have offered to add the appid (as used by AMO) to the JSON. Implementation suggestion: rather than rewriting aggregation code, processor to rewrite the product name for specified crashes.

Bug list

Affected components

Please provide scope notes and time estimates for your component.

  • Breakpad (ted) - bug 706560 - easy change to add appid
  • Processor (lars) - bug 706612 - assumptions in the bug - 1 day of work or less
  • PostgreSQL (jberkus) - bug 706893, bug 706899
  • Search (adrian) - bug 706892 - depending on how data changes in PSQL and ES, can be literally nothing to 1 day of work
  • FTP scraper (rhelmer) - worked around lack of bug 706711, see "FTP scraper/releases raw info" below
  • ADU reporting (deinspanjer) bug 706704 - 3 days work
  • QA (mbrandt)

Open Questions

  1. how do we get the information on each branch of Fennec from FTP-scraping? bug 706711
  2. are we sure that the list of products isn't hardcoded into the UI/Middleware anywhere? bug 705836
  3. we need a list of products+productIDs to check out List of current ones, don't have the native one yet

FennecAndroid on crash-stats-dev

The PostgreSQL database has been populated with fake crash data for FennecAndroid on crash-stats-dev. This includes the following fake data:

1) Versions 9.0, 10.0 and 11.0 of Fennec have mirrored versions and builds for FennecAndroid.

2) Matviews have been rebuilt from 12/8 to 12/11

3) 50% of Fennec crashes have been randomly reassigned as FennecAndroid

This is for testing so that we can see if FennecAndroid-related stuff works.

FennecAndroid on staging (

crash-stats.a.o (Stage) is also getting some fake data for testing FennecAndroid, but considerably less of it.

1. We've created fake versions 11.0a1, 11.0a2, 11.0b1, and 11.0 of FennecAndroid in the database. Build numbers are as follows:

Version ReleaseChannel BuildID
11.0 release 201112151030291
11.0 beta 201112081030291
11.0a2 aurora 201111291030291
11.0a1 nightly 201111221030291

There are also genuine FennecAndroid 11.0a1 releases starting about a week ago.

2. We will add FennecAndroid crashes for these versions and builds via the staging crash submitter. rhelmer will work with mbrandt on this.

Starting with the following data:

  • 8 unique signatures extracted from prod
    • 4 from Fennec 8.0
      • 7d1d0786-29d6-4950-94c6-2b91c2111218
      • da9fa4e0-2774-4914-9f58-fdfe02111218
      • a9c7ca73-e8c6-41f6-84b6-17a6f2111218
      • f42d9a77-e915-4f3a-894a-3a8d22111218
    • 4 from Fennec 11.0a1
      • 2e74f3da-b02d-4147-8a4e-b7a922111218
      • dd202188-2d0f-4135-9e41-d24aa2111218
      • 812f40d5-ffc2-4691-8c23-01b272111218
      • ecd0ca49-fcf1-465c-a71c-3af5b2111219


  • automated adding of fennec-nativeui builds: unable to estimate, as we currently have no information on how we will get data on new builds from FTP.
    • minimum: 5 hours (assumes easy & clear single criteria to pull new products from FTP feed)
    • maximum: 25 hours (assumes requirement to build new UI for manual entry of Fennec products)
    • bug: [1]
  • adding appids-product table: 1 hour bug: [2]
  • adding new products: 1 hour bug: [3]
  • testing & deployment: 5 hours

Stuff I need specifications for:

  • the list of new "Fennec-*" product names.
    • Fennec and FennecAndroid
  • how we're getting data from FTP scraping.
    • rhelmer working on this
      • see "FTP scraper/releases raw info" below
  • what Lars needs out of an appid table - call it ProductID please
    • e.g. Products (ProductID, ProductName) - there will be only five rows in this table atm. It will load at processor startup and be cached locally on the processors. The data will change very very rarely (e.g. once a year).
    • Most data is on AMO, waiting on dougt for the new one

QUESTION: Camino does not have a GUID? What should we do about it?

FTP scraper/releases raw info

Per bug 706711 we will not have consistent platform names across nightly/release in time. Current plan is to use the following columns to identify the builds as they are currently laid out on FTP:

  • Native release/beta
    • platform: android
    • repository: mozilla-release/mozilla-beta
    • build_type: Release/Beta

WARNING: we have old releases which match the above, and are not android-native. I've coded around this issue for the time being, but it is an indication of likely breakage with future releases -- Josh

  • Native nightly/aurora
    • platform: android-arm
    • repository: mozilla-central-android
    • build_type: Nightly/Aurora
  • XUL release/beta
    • platform: android-xul
    • repository: mozilla-release/mozilla-beta
    • build_type: Release/Beta
  • XUL nightly/aurora
    • platform: android-arm
    • repository: mozilla-central-android-xul
    • build_type: Nightly/Aurora

For example:

product_name | version |  platform   |    build_id    | build_type | beta_number |repository
mobile       | 11.0    | android     | YYYYMMDDhhmmss | Release    |             | mozilla-release
mobile       | 11.0    | android     | YYYYMMDDhhmmss | Beta       |           1 | mozilla-beta
mobile       | 11.0a1  | android-arm | YYYYMMDDhhmmss | Nightly    |             | mozilla-central-android
mobile       | 11.0    | android-xul | YYYYMMDDhhmmss | Release    |             | mozilla-release
mobile       | 11.0    | android-xul | YYYYMMDDhhmmss | Beta       |           1 | mozilla-beta
mobile       | 11.0a1  | android-arm | YYYYMMDDhhmmss | Nightly    |             | mozilla-central-android-xul