We need device builds which will be the actual final builds that we'll ship for v1. gaia locales: en-US, es, pt-BR gecko locales: TBD* *) it will be either all Fennec locales, or a subset of them. I'll update this bug when I know the precise requirements.

All the information we have right now says that we'll be handing off source, not binaries, to vendors. Closing this as WONTFIX based on that, but it wouldn't shock me if that changes.

14:45 < akeybl> all the information I've gotten points to Mozilla only maintaining a source repo and builds/updates for internal testing 14:45 < akeybl> we'll still converge on a 6-week cycle, but only with a deliverable of having the repo in order 14:45 < akeybl> for use by vendors 14:47 < akeybl> You can consider that the final say - we should not be planning for official builds/updates, only internal. If that situation changes, it'll have to be built into the schedule. 14:47 < akeybl> you can quote me

Reopening. Per Chris Lee: developers will be concentrating on Otoro shortly, and this will be closer to what we're shipping than Unagi. He specifically asked we reopen this bug as a 3-locale Otoro nightly (pt-BR, es, en-US), and we can potentially drop another build type (currently we're eyeballing the 50-locale Unagi nightly as the one to drop).

Aki: I suggest we have 6 locales: (pt-BR, es, en-US, ar, fr, zh-TW). This is the same list as bug 812833, but my understanding is that while bug 812833 is about Unagi builds, this bug is about Otoro. Adding ar, fr, and zh-TW makes developer testing easier: they can check for font rendering issues, sizing and right-to-left problems. I don't see why we'd want to limit the locales to (pt-BR, es, en-US) on these nightlies if their primary purpose if testing.

(In reply to Aki Sasaki [:aki] from comment #3) > Reopening. > > Per Chris Lee: developers will be concentrating on Otoro shortly, and this > will be closer to what we're shipping than Unagi. I'm not trying to be nitpicky, but for posterity: what this bug was originally asking for "builds that we'd actually ship" is different than otoro builds. With that said, I don't care that we're morphing this bug.

(In reply to Staś Małolepszy :stas from comment #4) > Aki: I suggest we have 6 locales: (pt-BR, es, en-US, ar, fr, zh-TW). This > is the same list as bug 812833, but my understanding is that while bug > 812833 is about Unagi builds, this bug is about Otoro. > > Adding ar, fr, and zh-TW makes developer testing easier: they can check for > font rendering issues, sizing and right-to-left problems. > > I don't see why we'd want to limit the locales to (pt-BR, es, en-US) on > these nightlies if their primary purpose if testing. I don't have any objection here. (In reply to Ben Hearsum [:bhearsum] from comment #5) > (In reply to Aki Sasaki [:aki] from comment #3) > > Reopening. > > > > Per Chris Lee: developers will be concentrating on Otoro shortly, and this > > will be closer to what we're shipping than Unagi. > > I'm not trying to be nitpicky, but for posterity: what this bug was > originally asking for "builds that we'd actually ship" is different than > otoro builds. With that said, I don't care that we're morphing this bug. Yeah, it was either reopen and morph or file new. Since the intention is similar ("build something closer to what we'll ship, for the purpose of testing similar-to-shipping-bits"), we decided to reopen.

Given comment 3, milestoning for C2.

Axel, who should own this? Releng or l10n?

This is me.

Just want to summarize the state of this bug because it's C2 and not finished yet. With bug 817108 being resolved as INVALID, we're waiting for bug 818032 to be fixed, then we can enabled these builds in production. Doing so is a simple flip of a switch.

I started writing this to try to get some automated testing for bug 817197 comment 5, and then realized I have no clue how to do separate make invocations when build.sh is involved. I might have an easier time testing that via MBF hacking :(

Status update: Multilocale Gaia is now enabled for the RelEng Otoro builds (all branches). QA has tested it and it appears to be working fine modulo already known bugs. Still left to do here is enabling multilocale Gecko after dependent bugs are fixed.

Status update: I'm currently doing initial test builds for otoro with multilocale gecko enabled. I will be handing these to QA to look at, and if things look good I'll be enabling multilocale gecko for devices soon afterwards. I need the Gecko patches from both bugs 812833 and 819979 to be reviewed and approved before enabling on mozilla-central. I also need the gecko patches from bug 796051 and 817197 uplifted to aurora/beta/b2g18 before I can enable multilocale gecko for devices on those branches.

I was able to get multilocale gecko builds for otoro with the patches in bug 812833, but due to bug 821296, I wasn't able to test them. That bug doesn't seem to be related, so I'm going to be enabling these today.

This happened as part of bug 812833.