Big Picture View: L10n Releng/Build work, 2017

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Big Picture View: L10n Releng/Build work, 2017

Justin Wood
Hey Everyone,

I want to share with you all the big picture view of where I see L10n
(L20n too) Automation over the course of this next year.

Last week in Hawaii, myself, Pike, gps, and mshal met and discussed
the overall plan and what we need from each other, we discussed what
my rough plan is as well, and since we all seemed to be on the same
page as "this makes sense" and some of "That's where I'd like it too".
I figured now is as good a time as any to share it.

* First, get all L10n repacks (currently based on nightly code) into
Taskcluster, so being based on in-tree code, and inspectable.
  -- Includes cross-compiled-on-linux OSX repacks.
* Reduce mozharness code for l10n greatly, to simplify what we are
staring at, (remove buildbot bits once we no longer need buildbot for
l10n)
* Create on-checkin jobs for l10n repacks, that operate on a small set
of (stable) locales and are based on the opt varients of the
platforms.
* Lastly, move away from mozharness entirely, in favor of a simplified
approach using `./mach` machinery in tree
   -- This could include, or be future-work to allow artifact build l10n.

We'll keep it all testable on try, and with-in-tree hacking
(documented) allowed to extend the list of locales used for various
bits too.

A Blue Sky approach that may or may not happen in 2017 from my seat:

* (discoverable somehow) Taskcluster jobs based on any checkin to the
various l10n repos
   -- These jobs would be a repack of whatever gecko repo(s) they apply to.
   -- Would produce xpi's, but not (necessarily) full binaries.
   -- Could include a job (or some jobs) that produces screenshots of
various parts of the UX, similar to some of the work you may have seen
around Firefox for iOS localized screenshots.

Most of this work does not yet have bugs on file, but I wanted to
share it early.

Thank You,
~Justin Wood (Callek)
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RelEng] Big Picture View: L10n Releng/Build work, 2017

Jordan Lund

[one comment in line]


On Mon, Dec 12, 2016 at 8:00 AM, Justin Wood <[hidden email]> wrote:
Hey Everyone,

I want to share with you all the big picture view of where I see L10n
(L20n too) Automation over the course of this next year.

Last week in Hawaii, myself, Pike, gps, and mshal met and discussed
the overall plan and what we need from each other, we discussed what
my rough plan is as well, and since we all seemed to be on the same
page as "this makes sense" and some of "That's where I'd like it too".
I figured now is as good a time as any to share it.

* First, get all L10n repacks (currently based on nightly code) into
Taskcluster, so being based on in-tree code, and inspectable.
  -- Includes cross-compiled-on-linux OSX repacks.
* Reduce mozharness code for l10n greatly, to simplify what we are
staring at, (remove buildbot bits once we no longer need buildbot for
l10n)
* Create on-checkin jobs for l10n repacks, that operate on a small set
of (stable) locales and are based on the opt varients of the
platforms.
* Lastly, move away from mozharness entirely, in favor of a simplified
approach using `./mach` machinery in tree
   -- This could include, or be future-work to allow artifact build l10n.

This last one caught my eye. I'm all for removing complexity and if, in the Taskcluster world,  mozharness more or less sets up an env and calls `./mach build`, this sounds like the right thing to do. However it would be great to keep l10n consistent with en-us builds and other variants. So removing mozharness from those and simply using `mach -> 'build sys'`. I wonder what gps and mshal's thoughts are with regards to this.

side, but related, note: tests are a different beast and I still see value keeping mozharness there. Maybe to line tests up with builds, we switch to mach being the interface that taskcluster uses: `mach -> mozharness -> 'sub test suite'`. That way we have mach be the one interface in all CI automation in both developer and taskcluster work flows.


We'll keep it all testable on try, and with-in-tree hacking
(documented) allowed to extend the list of locales used for various
bits too.

A Blue Sky approach that may or may not happen in 2017 from my seat:

* (discoverable somehow) Taskcluster jobs based on any checkin to the
various l10n repos
   -- These jobs would be a repack of whatever gecko repo(s) they apply to.
   -- Would produce xpi's, but not (necessarily) full binaries.
   -- Could include a job (or some jobs) that produces screenshots of
various parts of the UX, similar to some of the work you may have seen
around Firefox for iOS localized screenshots.

Most of this work does not yet have bugs on file, but I wanted to
share it early.

Thank You,
~Justin Wood (Callek)
_______________________________________________
release-engineering mailing list
[hidden email]
https://lists.mozilla.org/listinfo/release-engineering


_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Loading...