This is usually wrapped up in some other already-occuring daily communication like updates. For B2G we might need to piggyback something other than update pings due to bandwidth costs and constraints in the target markets. So: * need determination of best approach for ADU tracking * need implementation in Firefox OS client code * need support on server to handle the ping * need metrics content support for tracking the new product

Looks like Firefox switched to the plug-in blocklist ping. URL parameter construction is here: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/nsBlocklistService.js#414

(In reply to Dietrich Ayala (:dietrich) from comment #1) > Looks like Firefox switched to the plug-in blocklist ping. URL parameter > construction is here: > http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/ > nsBlocklistService.js#414 Right. I believe ADUs is calculated as the summation of all blocklist pings per day. The blocklist pings once per day as well for a FF profile. (In reply to Dietrich Ayala (:dietrich) from comment #0) > This is usually wrapped up in some other already-occuring daily > communication like updates. > > For B2G we might need to piggyback something other than update pings due to > bandwidth costs and constraints in the target markets. > > So: > > * need determination of best approach for ADU tracking Ask Daniel from the metrics engineering team. Note that what's ever figured out here also needs to work with Socorro for crash stats (cc-ing Kairo and Laura for this). > * need implementation in Firefox OS client code I wonder if bug 773117 (blocklisting for apps) could help out here in someway, although I haven't seen much activity on that bug on how that implementation works. Lucas - Has there been any thought to doing some sort of blocklist ping for blocklisting of apps? > * need support on server to handle the ping > * need metrics content support for tracking the new product Daniel - Thoughts?

We discussed this during triage today. cjones suggested that a lot of the information that we normally collect with blocklist pings can come from cellular providers. Is there something we won't be able to get from our partners? Should we discuss this on dev-b2g?

(In reply to Andrew Overholt [:overholt] from comment #3) > We discussed this during triage today. cjones suggested that a lot of the > information that we normally collect with blocklist pings can come from > cellular providers. Is there something we won't be able to get from our > partners? Should we discuss this on dev-b2g? We will need our own, internally vetted, source of truth. There will inevitably be differences in not only the means of collection, but also in the dimensions that folks find meaningful, and that affects rollups, etc.

I've started talking about this need to a few people. I do definitely think we should strive to put something in that we own for our vested interests. If we just rely on partners to provide us the data, we are severely limiting our ability to trust and understand the data. I am trying to put together a preliminary proposal for some things that we would likely want to collect for analysis. I'll make sure that is shared with interested people as soon as the first draft is finished and reviewed by Gilbert and Jay.

Maybe we'd like to do this right away as a minimal version of the MDP (whatever it will be called in the end)?

Based on comment #4 and other comments I've seen elsewhere, this is a v1 blocker. It also feels like a feature to me.

This is something I'd be interested in implementing. However, comment #5 implies Daniel is on it?

We are working with Services Engineering to get the core patches for FHR (tracking bug 718066) reviewed. We have already developed a patch for B2G with FHR and tested having it submit to our data collection service. We are trying to get some more info from various parties on what the most appropriate next steps are, but we hope that we can move forward with porting this patch over to B2G instead of hacking in a fake blocklist ping. I'll post here as soon as I have a bit more info.

Thumbs up from me on trying to get the MVP for FHR landed instead of doing something new for B2G. Greg and I will discuss. Daniel, is that patch hanging around on Bugzilla somewhere for Greg to look at?

Yep, I'll get mreid to post it here.

With a small tweak to the build files, the patches from Bug 718067 apply (and successfully submit) on B2G. I'm also attaching a patch to strip out some of the unneccessary data (such as addon info) and add in a proof-of-concept for including info about apps.

Build file change

An initial attempt to strip out some un-useful data from the payload, and add in a rudimentary placeholder for Apps info.

I am landing the core FHR code in bug 718067. Having a framework/service/API in place is a prerequisite to having B2G send any data. Therefore, there will be no movement on this bug until things start landing in bug 718067 (or dependent bugs).

We're marking this bug with the C1 milestone since it follows the criteria of "unfinished feature work" (see https://etherpad.mozilla.org/b2g-convergence-schedule). If this work is not finished by Nov19, this bug will need an exception and will be called out at the upcoming Exec Review.

Comment on attachment 670502 [details] [diff] [review] Patch to include FHR in B2G package manifest. This is now obsolete, newer code is in bug 808219.

Comment on attachment 670504 [details] [diff] [review] Patch to modify FHR payload to suit B2G This is now obsolete, newer code is in bug 808219.

Since I keep getting emails from b2g release drivers about this bug, I wanted to state explicitly on this bug that this feature is complete (to the best of my knowledge) and sitting on the larch project branch. I am awaiting landing approval from people who aren't release drivers. If you have any questions, please talk to :mconnor or :clee.

Marking for C2, given this meets the criteria of known P1/P2 blocking-basecamp+ bugs at the end of C1.

Who in legal/privacy is responsible/capable of signing off on this?

Connor is working this issue with Jay and Chris Lee.

update please? last update is from a week ago!

The team is working on a proposal right now and will send out an update as soon as we have a path forward. Thanks.

how long is that going to take?

I spoke with mconner about this today. As he explained it, this bug is a basecamp requirement. We will not ship FHR in B2G v1. Assigning to clee as he will come back with the proposal for how we want to obtain this data in v1.

Giving to Chris while he and others come up with a plan.

https://hg.mozilla.org/integration/mozilla-inbound/rev/7930f7397b4f This will need to be uplifted, but I'll wait to see if it breaks anything first…

Comment on attachment 694084 [details] [diff] [review] Pref off FHR on B2G. v1 Approval: turning off FHR build on B2G, because apparently that's no longer the implementation strategy for v1.

Not setting fixed flags, because this is just undoing a pref-on. https://hg.mozilla.org/releases/mozilla-aurora/rev/bd5fed24b6ee https://hg.mozilla.org/releases/mozilla-b2g18/rev/c5fb80143cdf

So we've had a series of meetings and we have a plan. As a first attempt we're going to use the appcache update check for the marketplace app. Morphing this bug into a meta-bug to cover the work needed for that to happen. We think that all the on-device work that needs to happen has already happened. But there's still work remaining on the server side to collect the data and try to weed out duplicate pings due to users opening the app (which also results in an appcache ping). So please file bugs blocking this one for the work needed, client side or server side.

This patch changes the way we process installation of external hosted apps at first run or when updating. The current behavior is to let them in /system/b2g, which means that we can't update them and thus we don't ping the marketplace manifest. With this patch, we move preinstalled *hosted* apps out of /system/b2g to /data/local like we do with preinstalled 3rd party packaged apps. This way we can update their manifest, and so we ping them.

Renoming since this is no longer a meta bug.

Jonas is going to file a new bug for Fabrice's work since this bug involves a lot of other things.

Comment on attachment 699592 [details] [diff] [review] patch Review of attachment 699592 [details] [diff] [review]: ----------------------------------------------------------------- I'll move the patch to Bug 828190

is this a dup of bug 860571 ? OR should this remain open? I'm not sure since this bug has a patch for turning of the health.

We can close this. When FHR ever gets turned in, there'll be a new bug.