Closed Bug 812835 Opened 12 years ago Closed 12 years ago

Set up nightly multilocale B2G Unagi builds for l10n testing

Categories

(Release Engineering :: General, defect)

defect
Not set
normal

Tracking

(blocking-basecamp:-)

RESOLVED WONTFIX
blocking-basecamp -

People

(Reporter: stas, Unassigned)

References

Details

I'd like us to start producing special multilocale builds of B2G for localization testing.  While bug 812833 is about adding a few locales to our regular Unagi builds (in order to allow the testing of locale changing, font rendering etc), this bug is about providing mass-multilocale builds for our localization community.

gaia locales: all Gaia locales (see https://hg.mozilla.org/gaia-l10n/)
gecko locales: all Fennec locales
Assignee: nobody → bhearsum
The current unagi builds are Mozharness based. Here's a rough outline of what I think we need to do:
* Add an action to https://github.com/mozilla/build-mozharness/blob/master/scripts/b2g_build.py that will clone l10n repos. It will need to run after Gaia is cloned, and be pointed at a language.json file to read the list of locales it needs.
* Pass something to the build system to tell Gaia which language.json file to use. Might need to be passed indirectly through https://github.com/mozilla-b2g/B2G/blob/master/flash.sh#L174
* Pass something to the build system to indicate which directory the l10n repos will be in. Again, this may have to be forwarded in flash.sh

After those things, we should end up with a multilocale unagi build. Still not sure where we're going to alter the existing nightly unagi build for this or add a new one.
Now that we're reopening bug 812831, Chris Lee suggested we might remove one of the four other builds from our Dec10 list.  This one is a prime candidate.
Agreed.  It looks like it would be hard to make these device builds available to the community right now.
This bug is only trivial work on top of bug 812833 (extra languages file + builder), so taking it out of the equation doesn't really give us back any human time. I'm not necessarily opposed to WONTFIX'ing, especially given that we don't have a legal way to distribute it, but closing this bug doesn't free up any resources for bug 812831.
I'm hoping once bug 813826 is fixed (Otoro dep builds), bug 812831 will be similarly easy.
Depends on: 815189
blocking-basecamp: --- → +
Target Milestone: --- → B2G C2 (20nov-10dec)
Because of the fact that we have no way to distribute these, I'm not planning to enable them anytime soon. And based on comments 2 and 3, I don't think this blocks the C2 milestone.
Assignee: bhearsum → nobody
Target Milestone: B2G C2 (20nov-10dec) → ---
I suspect this doesn't block basecamp either, but I don't have a full understand of what that means...so I'll leave that flag intact for now.
Minus as per #6.
blocking-basecamp: + → -
(In reply to Staś Małolepszy :stas (traveling) from comment #3)
> Agreed.  It looks like it would be hard to make these device builds
> available to the community right now.

Just to make sure I understand correctly: we're not legally allowed to distribute these builds outside of MoCo, right? And most localizers don't have unagi or otoro devices anyways, so even if they had the bits they wouldn't be very useful?

I'm at point where it's probably not too difficult to turn these on, so if there's a use case for them we can look at doing that. However, because of the reasons noted above I'm starting to think that this is a WONTFIX for the time being.
Blocks: 818560
No longer blocks: 818560
Depends on: 818560
I'm closing this because we currently have no way to legally distribute these builds, and there's no plans to figure out how to make these useful. If the situation changes we can re-open.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → Release Engineering
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.