Oh, I didn't realize A*Team was tackling this already. Great for them!
Looking at the Etherpad, it appears their goals aim to make sense of the
current mess we have in release automation. Those are noble goals that
we need to work towards. But I think my proposals go a bit further.
I see l10n as something that is broken starting from its implementation
in the build system. I believe a lot of the complexity in release
automation is derived from implementation details in the build system
and that release automation could be made much simpler by changing the
build system. I believe a lot of the complexity stems from years of
organic growth and shifting requirements.
Maybe I'm suffering from "if you are a hammer everything looks like a
nail" and I'm not seeing the full context here. I, like everyone else,
can't make claims that I fully understand l10n packaging :)
On 11/14/14 2:32 PM, Axel Hecht wrote:
The A-Team actually pinged me about a conversation about what can be
improved on the automation front for l10n.
https://etherpad.mozilla.org/ateam-l10n-automation has the notes for that.
In terms of people, I think bsmedberg is more on the historic context
side. rnewman does a bunch of l10n related stuff on android. A-Team and
dminor and edmorley, and mdoglio.
Reading through your questions, I'm not sure if they all have the same
target audience, and given how tight the time becomes in PDX, we might
have better chances if we split things out.
Axel
On 11/14/14 8:54 PM, Gregory Szorc wrote:
Packaging and l10n repacks in particular continue to be a major thorn in
our collective side. Their implementation constitutes a significant
barrier to making builds and automation faster. I think it would be
awesome if all the cooks could get together in Portland and bang out an
ideal end state for packaging/l10n of Firefox. We would strive to
produce a set of milestones for attaining real wins in 2015 or 2016.
Here are the people I think are most relevant:
* glandium
* mshal
* catlee
* jlund
* nalexander
* axel (or someone else who knows Firefox l10n processes and systems)
* (maybe) ted (for historical context)
I think most (all?) of us are in the Platform group, so we should all be
in the same location. Should we set aside a few hours one day to
collectively commit to a path forward?
====
For reference, here is a partial list of things that are broken or
inefficient:
* jar.mn files aren't processed efficiently as part of the build (we
process them every build and this isn't a no-op). (jar.mn files are used
to define l10n files)
* The Makefile hackery for nearly everything packaging and l10n related
is eye-gouging bad. See mozapps/installer/packager.mk and
toolkit/locales/Makefile.in if you dare. There is essentially a shadow
build system related to packaging and l10n repacks that makes optimizing
or changing things extremely difficult.
* Testing around packaging and l10n is horrible to non-existent. l10n
jobs can break and we won't find out until a train uplift.
* Separate automation jobs per locale can be grossly inefficient,
slowing down the time it takes to produce a release (possibly a
chemspill) and wasting infrastructure in the process.
* There are gazillions of l10n repositories on hg.mozilla.org. I think
there is potential for consolidation.
* Very little developer visibility and understanding of how packaging
works, especially l10n packaging (although I think this is getting
better with code moving in tree).
* Some have questioned the necessity of multi-locale or single-locale
packages on certain platforms (notably Android - Nick knows more).
Essentially, packaging and l10n is turtles all the way down. I don't
think anybody who has worked with these systems wouldn't throw gasoline
on and torch things if given the opportunity. Let's plan a bonfire.
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
