> -----Original Message----- > From: dev-builds [mailto:dev-builds- > bounces+rstrong=mozilla....@lists.mozilla.org] On Behalf Of Joshua Cranmer > ?? > Sent: Friday, November 14, 2014 1:26 PM > To: dev-builds@lists.mozilla.org > Subject: Re: Tackling l10n and packaging in Portland > > On 11/14/2014 1:54 PM, Gregory Szorc wrote: > > For reference, here is a partial list of things that are broken or > > inefficient: > > To add: the package-manifest.in is nothing short of a footgun. If you add > a new > component, component manifest, xpidl module, non-omni.ja file, etc., you > will > break releases if you forget to add it to the package manifest. If you add > in to a > shared component like, say, toolkit, you potentially have to modify up to > seven > package manifests to make it work. And if it's not exercised in a test, > you'll > virtually guarantee that no one will notice it missing (this caused us to > stop > collecting Telemetry data until someone said "oy, why don't we have any > telemetry data?"). > > I've tried building a shared toolkit package manifest before, but the > current > ones are an orgy of partially-duplicated insanity and, given that I don't > have > build systems set up for b2g or android, it's more or less beyond me to do > the > requisite testing to make anything stick. I have as well https://bugzilla.mozilla.org/show_bug.cgi?id=526333
At least updating removed-files.in is no longer required except in the most rare of cases. Robert > > > > * 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. > > > > * 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). > > Despite being the comm-central build system peer, I have no idea: > 1. How l10n repacks work > 2. How to test an l10n repack manually > 3. Where the buildbot code for l10n repacks lives 4. Where the status > results of > l10n repacks may be found > > -- > Joshua Cranmer > Thunderbird and DXR developer > Source code archæologist > > _______________________________________________ > dev-builds mailing list > dev-builds@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-builds _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
