After discussing this with aki and jberkus, I don't think Socorro will be able to reliably differentiate XUL UI from Native UI Fennec builds. We'd like to request that the application ID be added to the info.txt files, at least for mobile. The nightly builds look like this: http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2011-11-30-03-10-11-mozilla-central-android-xul/fennec-11.0a1.en-US.android-arm.txt This file contains the build ID (which we need), and we parse this path info into the following: product = mobile version = 11 build_type = nightly buildID = 20111130031011 repository = mozilla-central-android-xul platform = android-arm However release and beta builds will look something like this: http://ftp.mozilla.org/pub/mozilla.org/mobile/candidates/9.0b4-candidates/build1/android-xul_info.txt Note that the filename is "android-xul", so this will become "platform" when parsed. We could work around this if we could find a consistent platform name between the two, but aki tells me it's not easy to change for the nightly case. We could try to parse it out of the directory name in the nightly case, but the problem is we can't reliably parse "mozilla-central-android-xul" into "android-xul" since the first part ("mozilla-central") doesn't follow any generic convention (trying to split on "-" would fail "birch-android" for instance). We don't currently have a good way to get the list of valid repository names, so we could hardcode but this would be very fragile. Out of the available options, it looks like the one likely to cause the least pain is to add the app ID as well as the build ID to the info.txt files. I'd really like to avoid anyone having to carry a large, fragile hardcoded list. Please let me know if you see an easier way that I am missing!

Hm, still not sure how hard/easy it will be to add the app ID. However, we might be able to change the nightly file to android-xul_info.txt like releases ?

(In reply to Aki Sasaki [:aki] from comment #1) > Hm, still not sure how hard/easy it will be to add the app ID. > However, we might be able to change the nightly file to android-xul_info.txt > like releases ? This would solve the problem too.

Marcia, OK, I found the issue. The Mac Crashes you're looking for are from Firefox version 3.6. signature_counts aggregates only signatures from the "new" products, that is, 5.0 and later. I check for Mac crashes from FF 8.0 and there are quite a few in signature_counts, so that appears to be working. Therefore: I'm assigning this bug to Brandon to remove the 1% restriction from the middleware query. The rest of the issues reported by Marcia are documentation issues or known bugs; where can we document them?

Please ignore above comment. Due to some bugzilla bizarreness, that was for a different bug entirely.

(In reply to Aki Sasaki [:aki] from comment #1) > Hm, still not sure how hard/easy it will be to add the app ID. > However, we might be able to change the nightly file to android-xul_info.txt > like releases ? Aki: I see the info.txt file being created in ReleaseBuildFactory, but where does the nightly file get created?

(In reply to Chris Cooper [:coop] from comment #5) > (In reply to Aki Sasaki [:aki] from comment #1) > > Hm, still not sure how hard/easy it will be to add the app ID. > > However, we might be able to change the nightly file to android-xul_info.txt > > like releases ? > > Aki: I see the info.txt file being created in ReleaseBuildFactory, but where > does the nightly file get created? Looks like we would rename it here: http://hg.mozilla.org/mozilla-central/file/de720961a78d/toolkit/mozapps/installer/package-name.mk#l170 Though I we may be able to override it (maybe if it was MOZ_SOURCESTAMP_FILE ?= instead of = )? This is where we would add the app id, in theory: http://hg.mozilla.org/mozilla-central/file/de720961a78d/toolkit/mozapps/installer/packager.mk#l774 although I don't recall seeing the revision in the mobile .txt files ...? However, it's pretty easy to create an additional _info.txt file and add it to the additional upload files list, like we do in ReleaseBuildFactory.

Hey guys, any update on this? We need to ship support for native Fennec in Socorro by the end of the year, and we're waiting on this (or at least a solid confirmation of what the change is going to be.) We should probably change the summary too, if the solution will be changing the filename to be consistent across nightly/release rather than adding the app ID to the files.

Oh -- does it help to know that I removed uploadsymbols from android xul nightlies for this very reason in bug 703772?

(In reply to Aki Sasaki [:aki] from comment #8) > Oh -- does it help to know that I removed uploadsymbols from android xul > nightlies for this very reason in bug 703772? Umm, so we are not able to do any crash analysis for the tablet (i.e. XUL) builds any more? I feel nervous about that, given that Firefox 11 and 12 at least are supposed to have the XUL builds as the official release builds for tablets... We need to be able to analyze both XUL and "native" builds.

This is only on m-c, so we have two more merges before this code is in mozilla-beta. linux-android, aka android xul for Firefox 8, 9, 10, is still uploading symbols.

(In reply to Aki Sasaki [:aki] from comment #10) > This is only on m-c, so we have two more merges before this code is in > mozilla-beta. > linux-android, aka android xul for Firefox 8, 9, 10, is still uploading > symbols. Hm ok sorry if I am misunderstanding, but I thought the whole problem here is that we're going to be shipping release builds of android-native and android-xul at the same time. Is that not the case? If it is the case, then we're waiting on a resolution to this but in order to ship Socorro 2.3.5 on Monday (Dec. 19). We are ready to branch for QA except for this bug. Do you think that either the app ID can be added to the file, or we can rename (or add a new) info.txt so the platform name is consistent? If not we can try to put in some other workaround (or if we're wrong and native/xul android aren't shipping at the same time, I think it'll become a non-issue).

(In reply to Robert Helmer [:rhelmer] from comment #11) > (In reply to Aki Sasaki [:aki] from comment #10) > > This is only on m-c, so we have two more merges before this code is in > > mozilla-beta. > > linux-android, aka android xul for Firefox 8, 9, 10, is still uploading > > symbols. > > Hm ok sorry if I am misunderstanding, but I thought the whole problem here > is that we're going to be shipping release builds of android-native and > android-xul at the same time. Is that not the case? I have been told that Android native will not ship until Firefox 11. Therefore the Firefox 9 release on Dec 20, as well as the Firefox 10 betas built for the next 6 weeks, will not be native. Is this still an urgent issue for you?

(In reply to Robert Helmer [:rhelmer] from comment #11) > (In reply to Aki Sasaki [:aki] from comment #10) > > This is only on m-c, so we have two more merges before this code is in > > mozilla-beta. > > linux-android, aka android xul for Firefox 8, 9, 10, is still uploading > > symbols. > > Hm ok sorry if I am misunderstanding, but I thought the whole problem here > is that we're going to be shipping release builds of android-native and > android-xul at the same time. Is that not the case? Also, aiui, and as noted in comment 0, Socorro is currently able to differentiate beta and release build info.txt files. This bug is tracking nightlies only. Nightly android-xul is not uploading symbols to the symbol server, and will be obsoleted when Mobile switches gears from getting android native working on phones to getting android native working on tablets.

(In reply to Aki Sasaki [:aki] from comment #13) > (In reply to Robert Helmer [:rhelmer] from comment #11) > > (In reply to Aki Sasaki [:aki] from comment #10) > > > This is only on m-c, so we have two more merges before this code is in > > > mozilla-beta. > > > linux-android, aka android xul for Firefox 8, 9, 10, is still uploading > > > symbols. > > > > Hm ok sorry if I am misunderstanding, but I thought the whole problem here > > is that we're going to be shipping release builds of android-native and > > android-xul at the same time. Is that not the case? > > Also, aiui, and as noted in comment 0, Socorro is currently able to > differentiate beta and release build info.txt files. This bug is tracking > nightlies only. > > Nightly android-xul is not uploading symbols to the symbol server, and will > be obsoleted when Mobile switches gears from getting android native working > on phones to getting android native working on tablets. Oh ok, this is the first I've heard of this. So the nightly mozilla-central-android-xul builds will still be pushed (and presumably used by people) but there won't be symbols for them? I think this means that Socorro will get crashes and won't be able to tell them apart from native Android nightly crashes (they will still be processed, just symbols won't be resolved). We can tell releases apart, but (I just realized) this is presuming that xul and native builds will always have separate build IDs. Do you know if this will always be the case?

(In reply to Robert Helmer [:rhelmer] from comment #14) > We can tell releases apart, but (I just realized) this is presuming that xul > and native builds will always have separate build IDs. Do you know if this > will always be the case? Actually I take this back. So the crash reporter is going to be reporting the AppID (it'll be called "ProductID" in the crash report), but it's going to use the same product name for both XUL and Native builds. Socorro has a database table with the mapping of product_id->display_product_name. So it doesn't matter if they have the same buildID, we are using the info.txt files to identify which release a build came from (this is only really important for beta releases).

Comment on attachment 581712 [details] [diff] [review] add $(MOZ_APP_ID) to $(MOZ_SOURCESTAMP_FILE) [10:48] <ted> you can't do it that way, exactly [10:48] <ted> because that fucks up the file format [10:48] <ted> which is [10:48] <ted> <buildid> [10:48] <ted> <changeset link> [10:48] <ted> [<changeset link> ...]

(In reply to Aki Sasaki [:aki] from comment #13) > Nightly android-xul is not uploading symbols to the symbol server, and will > be obsoleted when Mobile switches gears from getting android native working > on phones to getting android native working on tablets. At least 11 and 12 will be shipped as XUL builds for tablets and native only for phones, from all I know, which means that right now we can't analyze crashes for the builds that will be released for tablets as we don't have symbols. I think turning those off was taking a wrong turn somewhere, not sure why. Also, because we will ship both in parallel to different devices, we will need to have infrastructure to support that and tell them apart - and that's what all this going back and forth over appID etc. is about.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #18) > (In reply to Aki Sasaki [:aki] from comment #13) > > Nightly android-xul is not uploading symbols to the symbol server, and will > > be obsoleted when Mobile switches gears from getting android native working > > on phones to getting android native working on tablets. > > At least 11 and 12 will be shipped as XUL builds for tablets and native only > for phones, from all I know, which means that right now we can't analyze > crashes for the builds that will be released for tablets as we don't have > symbols. Wrong; I turned off *nightly* symbols for android-xul. We will have symbols for release builds of android-xul. > I think turning those off was taking a wrong turn somewhere, not > sure why. Also, because we will ship both in parallel to different devices, > we will need to have infrastructure to support that and tell them apart - > and that's what all this going back and forth over appID etc. is about. As I stated multiple times in #build, we have been deprioritizing android-xul. I see the need for this, but I do not see it as a priority.

(In reply to Aki Sasaki [:aki] from comment #19) > Wrong; I turned off *nightly* symbols for android-xul. > We will have symbols for release builds of android-xul. Which means we can't analyze any crashes for the tablet release builds until they go out for release. Not really something I feel good with, given that tablets are probably a rapidly growing market. > As I stated multiple times in #build, we have been deprioritizing > android-xul. I see the need for this, but I do not see it as a priority. I didn't know that prioritization means that we don't care if we release a crashy product as we have no way to ensure stability before a release.

Ok, that didn't work. http://hg.mozilla.org/try/rev/ea91c4d31d1e

Try run for 18a3fce6c95d is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=18a3fce6c95d Results (out of 2 total builds): success: 2 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/asasaki@mozilla.com-18a3fce6c95d

Try run for ea91c4d31d1e is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=ea91c4d31d1e Results (out of 2 total builds): success: 2 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/asasaki@mozilla.com-ea91c4d31d1e

Strike 3. Either someone figures out what I'm doing wrong in makefile/mozconfig land, or I need to add buildbotcustom steps to create PLATFORM_info.txt files in nightlies the same way we do for release builds, or rhelmer can parse the directory name on ftp.m.o.

(In reply to Aki Sasaki [:aki] from comment #25) > Strike 3. > Either someone figures out what I'm doing wrong in makefile/mozconfig land, > or I need to add buildbotcustom steps to create PLATFORM_info.txt files in > nightlies the same way we do for release builds, or rhelmer can parse the > directory name on ftp.m.o. We're going to use the info from the directory name for now to take the pressure off (since we need to ship next week), but we'd still like to have the platform name be consistent since it'd simplify things on both sides, I think. Here's the plan for the next Socorro release (2.3.5): https://wiki.mozilla.org/Socorro:FennecAndroid#FTP_scraper.2Freleases_raw_info

Rob, Correct me if I'm wrong? From my viewpoint: a) we have an acceptable working solution in Socorro currently b) android-xul is scheduled to go away in 2-3 releases' time c) this bug seems to overlap with bug 548549 (unify release automation *_info.txt files with the ones generated by the build system) d) this bug differs with bug 548549 because there was more urgency on the mobile side, caused by the android native / android-xul shared update_platform confusion. If (a) and (b) are true and remain true for those 2-3 releases' time, (d) goes away and we can dup this bug to bug 548549. Are any of those assumptions incorrect?

(In reply to Aki Sasaki [:aki] from comment #27) > Rob, > > Correct me if I'm wrong? > From my viewpoint: > > a) we have an acceptable working solution in Socorro currently > b) android-xul is scheduled to go away in 2-3 releases' time > c) this bug seems to overlap with bug 548549 (unify release automation > *_info.txt files with the ones generated by the build system) > d) this bug differs with bug 548549 because there was more urgency on the > mobile side, caused by the android native / android-xul shared > update_platform confusion. > > If (a) and (b) are true and remain true for those 2-3 releases' time, (d) > goes away and we can dup this bug to bug 548549. > > Are any of those assumptions incorrect? All sounds correct to me, sounds like a dup of bug 548549 really.