712678 - Put Android-XUL Aurora and Nightly builds on separate update channels

Status: VERIFIED FIXED

(Release Engineering :: General, defect, P3)

Description

[Matt Brubeck (:mbrubeck)]

For Firefox 11 we are shipping two different products: Native Fennec and XUL Fennec.  We produce aurora and nightly builds for both products, but currently we have only one "aurora" and one "nightly" update channel.  This means that people who download the XUL Fennec nightly get updated to Native Fennec instead of XUL Fennec.

To enable people to test XUL Fennec on aurora and nightly, can we create separate update channels ("aurora-xul" and "nightly-xul"?) that will be used for the XUL builds and will receive updates to newer XUL builds?

(In a separate bug, we might also want to add "Android Tablet" download links to the nightly and aurora download pages.)

Comment 1

[Robert Kaiser]

I'm supporting this a lot, as it would be good to have reasonable amounts of users there so we get at least some crash analysis out of the builds we are shipping to the rapidly growing tablet market (also, I personally think that our current tablet UI rocks and the XUL builds are really good on tablets - contrary to phones).

Note that as soon as we know how the channels will be named, we probably will need a tiny change to get the new channel on Aurora (and Beta?) respected correctly on crash-stats as well, as we are currently matching the exact "aurora" (and "beta") string there to put the crashes in the correct buckets. (For Nightly, we already match "nightly*" and for finals "release*", so we probably use the same scheme for the other channels, which should be pretty easy, but it requires a change in DB queries and therefore it would be good to have a couple of days to implement it - can be done in parallel to getting it implemented for the builds and AUS.)

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

We could probably do as comment #0 suggests (with some buildbot and AUS changes), but perhaps it's better to modify the %BUILD_TARGET% instead. Currently we have 'Android_arm-eabi-gcc3' for both native and XUL builds, if that persists as far as betas and releases we won't be able to tell them apart ADU-wise.

If we have distinguishable targets then we don't need much on the releng side, just leave the channels as is and tweak 
http://hg.mozilla.org/build/buildbot-configs/file/282ba5b02c91/mozilla/config.py#l700
http://hg.mozilla.org/build/buildbot-configs/file/282ba5b02c91/mozilla/config.py#l750
We would need a compile time change, or a tweak to nsUpdateService.js to get the modified build targets into the update and/or blocklist requests.

Comment 3

[Robert Kaiser]

We already can tell them apart fine ADU-wise, as we have the appID there, which is different for the two products that those actually are ;-)

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

Hmm, but we don't get APP_ID in the AUS query.

Comment 5

[Robert Kaiser]

(In reply to Nick Thomas [:nthomas] from comment #4)
> Hmm, but we don't get APP_ID in the AUS query.

Right. The appID was created as an add-on-only concept - and ADUs are based on the add-on blocklist, which clearly is an add-on concept and therefore has had the appID "forever". Now with this having two different products (given that everything except the Gecko/platform core is different, it's safe to call them that) with the same name, the different appIDs have proven to be the only real thing to tell them apart, so we decided to also send it to crash-stats and "emulate" different products on the server there.

Unfortunately all that doesn't solve AUS a bit and we still need a solution there. Different update channels would be the easiest way to do it, but I guess if you find another good way, we'll be happy to hear about it.

Comment 6

[Daniel Einspanjer [:dre] [:deinspanjer]]

AUS passes the distribution name and version in addition to channel. could we use that as a difference to key on?

Comment 7

[Aki Sasaki (not active)]

Discovered recently: we need this same solution (whatever it is; I'm leaning towards BUILD_TARGET) to be able to provide separate android and android-xul updates for a beta or release.

Comment 8

[Robert Strong (they/them - no direct email)]

A simple option for a one-off like this is to add a unique value to the app.update.url preference.
http://mxr.mozilla.org/mozilla-central/source/mobile/android/app/mobile.js#533

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch

no idea if this is the right/complete fix or not, but hopefully this will get things moving

Comment 10

[Aki Sasaki (not active)]

I think altering the build target would be a one line patch on our side; altering the product would be a multi-line patch on our side.

Comment 11

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Modify %BUILD-TARGET% instead

This is what Aki had in mind, and I agree with him this is much better from a RelEng point of view. Our patch would just be http://pastebin.mozilla.org/1478470

This does diverge the ways to differentiate the two build types for AUS and blocklist, but we could make the same change to the blocklist query too. Any other issues ?

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 595145 [details] [diff] [review]
Modify %BUILD-TARGET% instead

Lets make sure any other followups are done before we bust blocklist or metrics or any other consumers

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 593889 [details] [diff] [review]
patch

going with nick/aki method

Comment 14

[Aki Sasaki (not active)]

Attachment: android-xul update_platform

This will need a reconfig.

Comment 15

[Aki Sasaki (not active)]

Comment on attachment 597289 [details] [diff] [review]
android-xul update_platform

I need to enable snippets for android-xul too.
I think it's just removing the |'create_snippet': False,| line, but I'd like to double check.

Comment 16

[Aki Sasaki (not active)]

Attachment: this changes the build target + enables android-xul updates

tested in staging.

Comment 17

[Robert Kaiser]

Comment on attachment 595145 [details] [diff] [review]
Modify %BUILD-TARGET% instead

>diff --git a/mobile/xul/app/mobile.js b/mobile/xul/app/mobile.js
>--- a/mobile/xul/app/mobile.js
>+++ b/mobile/xul/app/mobile.js
>@@ -1,9 +1,9 @@
>-/* ***** BEGIN LICENSE BLOCK *****
>+a/* ***** BEGIN LICENSE BLOCK *****

I trust this part of the patch won't actually land. ;-)

Comment 18

[Aki Sasaki (not active)]

Comment on attachment 597333 [details] [diff] [review]
this changes the build target + enables android-xul updates

http://hg.mozilla.org/build/buildbot-configs/rev/f68c9cba4c88

On the next reconfig (scheduled for Thurs), this should go live and we'll start publishing snippets for android-xul.

However, nothing will actually point here until the other patch (minus the typo) lands and we build an android-xul nightly.

Comment 19

[Aki Sasaki (not active)]

This is live.
Per comment 3, I think metrics has what they need; I think we can land attachment 595145 [details] [diff] [review] (without typo) and mark this RESO FIXED.

Comment 20

[Aki Sasaki (not active)]

Attachment: Updated android-xul build target patch without typo

Same thing, in needs-checkin friendly format, without the typo.
I think I'm going to push this to mozilla-inbound as ffxbld just to see this bug resolved.

Comment 21

[Aki Sasaki (not active)]

Comment on attachment 600548 [details] [diff] [review]
Updated android-xul build target patch without typo

http://hg.mozilla.org/integration/mozilla-inbound/rev/dba91788acba

1. this patch will build on m-i
2. this patch will merge to m-c
3. the first android-xul nightly built on m-c with this patch will start looking at the new snippet url, but will have nothing to update to
4. when the *second* android-xul nightly is built on m-c with this patch, the first android-xul nightly will update to the second.

We'll need to merge to m-a, or wait for Fx 13 to merge there, before android-xul updates work properly on Aurora.

Comment 22

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/dba91788acba

should this be resolved?

Comment 23

[Aki Sasaki (not active)]

Yay!

Comment 24

[Bill Gianopoulos [:WG9s]]

I verified that the 20120225 XUL nightly correctly updates to the 20120226 XUL nightly and also that the 20120225 Native nightly correctly updates to the 20120226 Native nightly.

Comment 25

[Bill Gianopoulos [:WG9s]]

Well this is marked as fixed as it is  fixed on trunk, but since the request was for Aurora as well I guess it is really not completely fixed until this lands on Aurora.

Comment 26

[Matt Brubeck (:mbrubeck)]

Comment on attachment 600548 [details] [diff] [review]
Updated android-xul build target patch without typo

[Approval Request Comment]
User impact if declined: Difficult to test XUL fennec on Aurora before releasing it to beta.

Testing completed (on m-c, etc.): Landed on m-c 2/25.

Risk to taking this patch (and alternatives if risky): Low-risk patch that changes one preference, and affects XUL Fennec only.  Since nightly/aurora updates are broken for XUL fennec without this patch, there's no real risk in trying to enable them.

String changes made by this patch: None.

Comment 27

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 600548 [details] [diff] [review]
Updated android-xul build target patch without typo

[Triage comment]
Yes, please!

Comment 28

[Aki Sasaki (not active)]

Comment on attachment 600548 [details] [diff] [review]
Updated android-xul build target patch without typo

http://hg.mozilla.org/releases/mozilla-aurora/rev/381310995e75