The schedule is going to be interesting, in particular because folks
maintaining the google doc don't know what we're planning in the l10n team.
That said, I think the a-team and the l10n packaging discussions can be
separate, or at least have little overlap in terms of content. Maybe in
terms of people, though.
Axel
On 11/24/14 6:08 PM, Jonathan Griffin wrote:
I've also scheduled Laurelhurst Friday @ 2pm for a similar discussion,
so we should figure out if we need both. :)
There is a large releng/a-team coordination meeting Tuesday from 3-5pm,
so there wouldn't be a lot of a-teamers available at the Tuesday time.
It may be we can use the Friday meeting for follow-up and to decide
where the A-Team is needed; from current discussions it looks like most
of this will be handled by build and releng.
Jonathan
On 11/24/2014 9:01 AM, Gregory Szorc wrote:
We now have the Laurelhurst Room on the 2nd floor of The Marriott
reserved at 1600 on Tuesday to discuss this.
It's only reserved for 1 hour. I didn't want to schedule in the 1500
slot because I figured people might be interested in the "B2G workflow
for Gecko hackers" talk. Unless you are going to Rogue Ales, we could
always run over without conflicting with dinner.
Please add it to your calendar.
On 11/14/14 11:54 AM, 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.
_______________________________________________
release-engineering mailing list
release-engineer...@lists.mozilla.org
https://lists.mozilla.org/listinfo/release-engineering
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
