Closed Bug 1000212 Opened 6 years ago Closed 6 years ago

decide what b2g/firefoxos update URLs look like

Categories

(Release Engineering :: Applications: Balrog (backend), defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: bhearsum)

References

Details

We need to decide what to put in all of the substitution fields:
/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/

Product: Almost certainly FirefoxOS
Version/OS Version: Seems like B2G version is the right thing for both of these, semantically. Do we need to to pass the Gecko or Gaia version anywhere?
Build ID: Looks like b2g has one.
Locale: Not sure what to do here. "multi" seems bad because it can correspond to different sets of locales. Perhaps it should be a csv list of all of the locales?
Channel: "nightly" is probably what we're using for all of the initial updates. I imagine we'll have other channels in the future.
Distribution/Distribution Version: AFAICT these are going to go unused for now.
Assignee: nobody → bhearsum
Bug 918068 comment #10 might actually apply here, should I re-post it to this one?
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #1)
> Bug 918068 comment #10 might actually apply here, should I re-post it to
> this one?

Yeah, please.
(In reply to Ben Hearsum [:bhearsum] from comment #0)
> We need to decide what to put in all of the substitution fields:
> /update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/
> %OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/
> 
> Product: Almost certainly FirefoxOS
> Version/OS Version: Seems like B2G version is the right thing for both of
> these, semantically. Do we need to to pass the Gecko or Gaia version
> anywhere?
> Build ID: Looks like b2g has one.
> Locale: Not sure what to do here. "multi" seems bad because it can
> correspond to different sets of locales. Perhaps it should be a csv list of
> all of the locales?
> Channel: "nightly" is probably what we're using for all of the initial
> updates. I imagine we'll have other channels in the future.
> Distribution/Distribution Version: AFAICT these are going to go unused for
> now.

Oh, and build target should be a unique identifier for the device. Maybe as simple as "flame", maybe not.
(In reply to Ben Hearsum [:bhearsum] from comment #0)
> Channel: "nightly" is probably what we're using for all of the initial
> updates. I imagine we'll have other channels in the future.

Our usual scheme of channels should be alright there. In the partner instructions at https://developer.mozilla.org/en-US/docs/Crash_Reporting_Guide_for_Firefox_OS_Partners#Release_Channels we are intentionally leaving out "aurora" as we always have only one version in stabilization between nightly and release and therefore can use "beta" during all that time and partners rarely do pre-production builds with any significant circulation anyhow.
For our own updates, it should be no problem if we use both "aurora" and "beta" or only "beta", whatever we find more useful (given we may want people to jump from 2.0 beta to 2.1 while that is technically on aurora, we may want to go only with "beta", but let's figure that out with B2G release drivers when we come to it).
(In reply to Ben Hearsum [:bhearsum] from bug 918068 comment #8)
> * Figure out what a b2g update URL looks like using /update/3 format
> (https://aus4.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/
> %BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/
> %DISTRIBUTION_VERSION%/update.xml).

We need to make sure those replacements even work in the B2G code. Some testing might be useful there.
It's probably the code in http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/mozapps/update/nsUpdateService.js#3542 that drives this for B2G as well.

> ** Some of this is obvious, but there's questions around a few things:
> *** Is %VERSION% the b2g version? What about %OS_VERSION%? Does %OS_VERSION%
> even mean anything in the b2g world? We could do %VERSION% = gecko version
> and %OS_VERSION% = b2g version, which might make more semantic sense.

I think %VERSION% is converted by the global code to be the Gecko version as it's also the version of the "B2G" product on the low levels of the binary.
Sending the B2G_OS_Version, i.e. the actual Firefox OS version string, in OS_VERSION makes sense, but this probably will need a patch to the product code. Right now, there is a token defined that is called %B2G_VERSION% that resolves to that version, maybe we should just put it in the URL instead of %OS_VERSION% for now.

> *** Does b2g have an overall buildid?

Yes, it's the Gecko build ID that we get there.

> *** What does "locale" mean in a multilocale context?

Probably nothing in this case.

What would make more sense is to send the device identifier in some field, see %PRODUCT_MODEL% in the code sited above. If we want to avoid changes to the URL format so that balrog doesn't need to support a different format, maybe that could go in for %DISTRIBUTION% or even %BUILD_TARGET% (after all, the build is created specifically for that device, which is even more detailed build target info than the usual variable) in the current format.
(In reply to Ben Hearsum [:bhearsum] from comment #3)
> Oh, and build target should be a unique identifier for the device. Maybe as
> simple as "flame", maybe not.

The %PRODUCT_MODEL% identifier mentioned in comment #5 should be unique per device already. And it might actually be "flame" for that device, I have no way to check that right now.
Thanks for all your comments KaiRo, they've been very helpful. Here's my proposal for what we should use:
* %PRODUCT%: FirefoxOS
* %VERSION%: Gecko Version
* %BUILDID%: BuildID
* %BUILD_TARGET%: Device identifier (probably %PRODUCT_MODEL%).
* %LOCALE%: csv of gaia locales.
* %CHANNEL%: if set, MOZ_UPDATE_CHANNEL, otherwise "default" (just like we do for desktop/android
* %OS_VERSION%: B2G Version (probably %B2G_VERSION%)
* %DISTRIBUTION%/%DISTRIBUTION_VERSION%: unused at this time, they'll probably end up as "default" or similar.

With regards to the locales, Aki pointed out to me that we have both Gecko and Gaia locales, which can be different. Gaia locales are the ones used by the OS though, so I think their list is what we care about. There's no clear use for this at this time, but we've run into many situations in the past where passing extra information ahead of time would've helped, so I think it's good to pass this as long as it's not technically challenging to do so.


So, an example request for a Flame could be:
https://aus4.mozilla.org/update/3/FirefoxOS/30.0/20140402010101/flame/ar,bg,bn-BD,ca,cs,da,de,el,en-US,es,eu,fr,gl,hr,hu,it,ja,km,ko,lt,mk,ms,ne-NP,nl,pa,pl,pt-BR,ro,ru,sk,sq,sr-Cyrl,sr-Latn,sv-SE,tr,zh-CN,zh-TW/nightly/2.0.0.0-prerelease/default/default/update.xml

I'm not sure who all needs to sign off on this, needinfo'ing a few folks though.
Flags: needinfo?(kairo)
Flags: needinfo?(fabrice)
Flags: needinfo?(bbajaj)
(In reply to Ben Hearsum [:bhearsum] from comment #7)
> Thanks for all your comments KaiRo, they've been very helpful. Here's my
> proposal for what we should use:
> * %PRODUCT%: FirefoxOS

Actually, if you use the %PRODUCT% as it comes, it will send "B2G" there.

> * %LOCALE%: csv of gaia locales.

I don't think it's useful to have a long list of locales returned there. Also, if you want this, we'll need a patch for the update service to actually send this, and that patch might not be trivial.
Everything else doesn't need actual code patches and can be done with the simple pref change in http://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#537

All the other parts you said look good from my POV.

If you put in this pref:
pref("app.update.url", "https://aus4.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%PRODUCT_MODEL%/%LOCALE%/%CHANNEL%/%B2G_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml");

You would (AFAIK) get a request like this with current code:
https://aus4.mozilla.org/update/3/B2G/31.0a1/20140402010101/flame/en-US/nightly/2.0.0.0-prerelease/default/default/update.xml

I think that probably would be alright, wouldn't it?
Flags: needinfo?(kairo)
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #8)
> (In reply to Ben Hearsum [:bhearsum] from comment #7)
> > Thanks for all your comments KaiRo, they've been very helpful. Here's my
> > proposal for what we should use:
> > * %PRODUCT%: FirefoxOS
> 
> Actually, if you use the %PRODUCT% as it comes, it will send "B2G" there.

OK. I guess that's fine. Doesn't really make a practical difference AFAICT.

> > * %LOCALE%: csv of gaia locales.
> 
> I don't think it's useful to have a long list of locales returned there.

It also wasn't useful to include service pack information for Desktop at one point...

> Also, if you want this, we'll need a patch for the update service to
> actually send this, and that patch might not be trivial.
> Everything else doesn't need actual code patches and can be done with the
> simple pref change in
> http://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#537

...but if it's technically difficult to do it, it doesn't seem like a blocker to me. I'm fine to make it "multi" or something else arbitrary.

> All the other parts you said look good from my POV.
> 
> If you put in this pref:
> pref("app.update.url",
> "https://aus4.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/
> %PRODUCT_MODEL%/%LOCALE%/%CHANNEL%/%B2G_VERSION%/%DISTRIBUTION%/
> %DISTRIBUTION_VERSION%/update.xml");
> 
> You would (AFAIK) get a request like this with current code:
> https://aus4.mozilla.org/update/3/B2G/31.0a1/20140402010101/flame/en-US/
> nightly/2.0.0.0-prerelease/default/default/update.xml
> 
> I think that probably would be alright, wouldn't it?

I think so.
I have no clue about the locale part, but the huge csv list looks strange to me. Otherwise looks fine.
Flags: needinfo?(fabrice)
Alexandre Lissy pointed me at http://www.kandroid.org/online-pdk/guide/build_new_device.html today, which talks about PRODUCT_MODEL being an end-user oriented thing ("End-user-visible name for the end product"). He suggested PRODUCT_DEVICE instead, which sounds more appropriate to me.
(In reply to Ben Hearsum [:bhearsum] from comment #11)
> Alexandre Lissy pointed me at
> http://www.kandroid.org/online-pdk/guide/build_new_device.html today, which
> talks about PRODUCT_MODEL being an end-user oriented thing
> ("End-user-visible name for the end product"). He suggested PRODUCT_DEVICE
> instead, which sounds more appropriate to me.

Well, for one thing, we are using the "model" thing everywhere else we refer to "what device is this", and for the other, %PRODUCT_MODEL% is what actually exists in the update code right now - anything else you would need to code up first.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #12)
> (In reply to Ben Hearsum [:bhearsum] from comment #11)
> > Alexandre Lissy pointed me at
> > http://www.kandroid.org/online-pdk/guide/build_new_device.html today, which
> > talks about PRODUCT_MODEL being an end-user oriented thing
> > ("End-user-visible name for the end product"). He suggested PRODUCT_DEVICE
> > instead, which sounds more appropriate to me.
> 
> Well, for one thing, we are using the "model" thing everywhere else we refer
> to "what device is this", and for the other, %PRODUCT_MODEL% is what
> actually exists in the update code right now - anything else you would need
> to code up first.

Well, I'm not too fussy. If PRODUCT_MODEL is set usefully everywhere for now, I guess we can stick with it.
I finally got a working build with this as app.update.url:
https://aus4-dev.allizom.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%PRODUCT_MODEL%/%LOCALE%/%CHANNEL%/%B2G_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml

Here's what it translated to:
https://aus4-dev.allizom.org/update/3/B2G/31.0a1/20140423040299/Flame/en-US/nightly/2.0.0.0-prerelease/default/default/update.xml?force=1

So, pretty much what we expected, except that I'm surprised Flame is capitalized. I'm not sure where that's happening. In any case, we can deal with.

I think we've decided what we're going to do now, so unless anyone else has something to say, we're all done! Thanks for all your help everyone.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(bbajaj)
Resolution: --- → FIXED
We changed our minds again in bug 1001542. We'll be using:
https://aus4-dev.allizom.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%PRODUCT_DEVICE%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml (PRODUCT_DEVICE instead of PRODUCT_MODEL and OS_VERSION instead of B2G_VERSION). That bug will be changing OS_VERSION to be something like "Boot2Gecko 2.0.0.0-prerelease". After that lands, we'll still need to change the update URL being used. That will happen in bug 1000207, probably just for Flame first.
You need to log in before you can comment on or make changes to this bug.