Last Comment Bug 723178 - Re-add performance metrics to AMO ping
: Re-add performance metrics to AMO ping
Status: RESOLVED FIXED
:
Product: MailNews Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: All All
: -- normal (vote)
: Thunderbird 13.0
Assigned To: Jens Hatlak (:InvisibleSmiley)
:
Mentors:
Depends on: 716736
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-01 10:09 PST by Jens Hatlak (:InvisibleSmiley)
Modified: 2012-02-20 10:18 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
fixed
fixed
fixed
fixed


Attachments
patch for TB&SM [Checkin: Comment 8] (3.68 KB, patch)
2012-02-01 10:09 PST, Jens Hatlak (:InvisibleSmiley)
standard8: review+
bugspam.Callek: review+
standard8: approval‑comm‑aurora+
standard8: approval‑comm‑beta+
Details | Diff | Splinter Review

Description Jens Hatlak (:InvisibleSmiley) 2012-02-01 10:09:12 PST
Created attachment 593502 [details] [diff] [review]
patch for TB&SM [Checkin: Comment 8]

+++ This bug was initially created as a clone of Bug #716736 +++

Bug 682356 landed ~2 months ago, removing the performance data from the metadata ping to AMO (effectively backing out bug 623950), after bug 668392 added the list of addons to telemetry. However, it turns out that the data from Telemetry is insufficient for AMO's needs. 

So bug 623950 needs to be re-landed (ie, undo the change bug 682356 did), but with the performance data only being sent when it's part of the periodic background update check.

Note that bug 682356 landed before the previous merge - so this fix will need to land on Aurora too.
Comment 1 Justin Wood (:Callek) (Away until Aug 29) 2012-02-03 17:07:51 PST
Comment on attachment 593502 [details] [diff] [review]
patch for TB&SM [Checkin: Comment 8]

I reviewed both patches, But I do feel that for at least branch landing of the TB ones, we need mark's rs or review. Approvals also require the dependent patch to land of the Firefox branches.

My one required change is to expand the %APP% into the app strings, since its what Firefox's patch did and I don't see any test from my glance here that does the APP expand for this pref.
Comment 2 Mark Banner (:standard8) 2012-02-06 11:19:18 PST
Comment on attachment 593502 [details] [diff] [review]
patch for TB&SM [Checkin: Comment 8]

r=Standard8. Please definitely make the %APP% -> thunderbird (and seamonkey) as Callek requested.
Comment 3 Mark Banner (:standard8) 2012-02-06 11:20:27 PST
I know it doesn't quite fit, but lets move this to mailnews core where we can track it landing for both apps.
Comment 4 Mark Banner (:standard8) 2012-02-06 11:20:52 PST
Comment on attachment 593502 [details] [diff] [review]
patch for TB&SM [Checkin: Comment 8]

I wondered if that might happen.
Comment 5 Jens Hatlak (:InvisibleSmiley) 2012-02-06 13:12:20 PST
(In reply to Justin Wood (:Callek) from comment #1)
> My one required change is to expand the %APP% into the app strings, since
> its what Firefox's patch did and I don't see any test from my glance here
> that does the APP expand for this pref.

(In reply to Mark Banner (:standard8) from comment #2)
> r=Standard8. Please definitely make the %APP% -> thunderbird (and seamonkey)
> as Callek requested.

Bah, two reviewers and it's me who needs to figure out the details in order for you to allow me to not repeat FF's mistakes... Well, here we go:

* I created the new extensions.getAddons.getWithPerformance.url pref as a copy of the *existing* extensions.getAddons.get.url pref (just one line above!), which *already and still does* use %APP% - for SM and TB, but not FF.
** If you look at the strings you'll easily see that %APP% is used in the exact same places (mind you: copy!)
** If the %APP% expansion wouldn't work, then extensions.getAddons.get.url would be broken, too!
** If I make the change you requested, we'll have an inconsistency and thus a greater chance for an unnoticed breakage.

Note: extensions.getAddons.get.url (and thus the copy, too) uses the variables %LOCALE%, %APP%, %API_VERSION%, %IDS%, %OS%, and %VERSION%.

So, what happens? (all Toolkit/Core code)
1. _beginGetAddons uses a local variable called "params" which unconditionally defines the variables API_VERSION and IDS, and conditionally TIME_MAIN, TIME_FIRST_PAINT and TIME_SESSION_RESTORED.
2. _beginGetAddons calls _formatURLPref with the "params" variable.
3. _formatURLPref substitutes anything from "params", then calls nsURLFormatterService.formatURLPref. What's left at this point is %LOCALE%, %APP%, %OS% and %VERSION%.
4. formatURLPref delegates to formatURL, which substitutes anything that member variable "_defaults" contains, among them LOCALE, APP, OS, and VERSION.

Blame will happily tell you that the "APP" line in "_defaults" has been changed the last time in 2008, but was present even before that. So it's not trunk-only and for sure on Aurora and Beta, too. Did I mention that extensions.getAddons.get.url would be broken, too, if that was not the case?

Now if I didn't convince you then it's of course your right to make the changes you required upon checkin, but in that case, please use your own name for the patch author field. I don't want to put my name under that change.
Comment 6 Justin Wood (:Callek) (Away until Aug 29) 2012-02-08 02:05:21 PST
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #5)
> Now if I didn't convince you then it's of course your right to make the
> changes you required upon checkin, but in that case, please use your own
> name for the patch author field. I don't want to put my name under that
> change.

As for me, I still think matching Firefox is better than diverging here, (for these metrics bugs we have traditionally matched firefox char for char except where we need to switch, like s/firefox/seamonkey/) Though given your investigation I won't bikeshed on this particular issue, so you can land that as-is. I just know I want to see this landed!

I can't speak for mark though.
Comment 7 Jens Hatlak (:InvisibleSmiley) 2012-02-15 12:57:24 PST
Mark: ping.
Comment 8 Mark Banner (:standard8) 2012-02-20 02:25:43 PST
Ok, I just did a bit more digging. The Firefox prefs used to be %APP%, it was bug 650246 that changed them.

Given that we use %APP% at the moment, lets be consistent. I don't see a need to port that bug unless requested.

Note You need to log in before you can comment on or make changes to this bug.