Re: Getting a Tier-X for localized builds. X=1
Axel Hecht <[email protected]>
| Newsgroups | gmane.comp.mozilla.devel.seamonkey |
|---|---|
| Message-ID | <[email protected]> |
On 21/01/16 18:37, Mike Hommey wrote: > On Thu, Jan 21, 2016 at 04:45:40PM +0800, Axel Hecht wrote: >> On 14/01/16 19:34, Chris AtLee wrote: >>> I think having a separate l10n repack per push for a small set of >>> relatively stable locales would go a long way towards detecting bustage >>> early. >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=848284 was filed a while back >>> to get l10n jobs available on Try and Inbound. I've taken a quick poke at >>> this, but haven't had a chance to test it. If we want per-push repacks on >>> inbound, we may want to take a different approach than the one I've taken >>> anyway. >>> >>> Is there someone who could help debug any issues that come up if we decide >>> to tackle this? >> >> I believe that we should tackle this. And I'm happy to help. >> >> I've also proven that I can be only of limited help, given how often I've >> broken the tree for two days past week. Finally even backing out my code. >> More on that in a separate reply. >> >> Broadly speaking: >> >> I think there would be two things to tackle first, one is to break out from >> repacking Nightlies. It sounded like a good idea at the time, but not any >> more. > > I disagree with this. Specifically, the problem is not with the idea of > repacking nightlies. That is actually sound. The problem is with the > implementation. Build jobs that are independent of nightlies, starting > from a possibly unrelated tree, driven by buildbot scripts (now > mozharness, thankfully, aiui) that drive make scripts, which means > configure must run before even knowing what the tree corresponding to > the nightly is because the makefiles will tell, then update the tree, > rerun configure because the tree changed, and then start running > makefile contraptions replicating part of the build system to build > langpacks that are then fed to the actual thing that does the repack. > And that's probably a simplified view of the mess this actually is. > > The thing is, if the jobs started from the result of the nightly jobs, > with the right tree, like, you know, test jobs do, the first part of > the horror show would go away. A proper build system to build a > langpack would kill another part. Then remains applying the langpack > to a new build, and that part, afaik, works, mostly. > We're saying the same thing, I guess. My statement wasn't about "repack", but about "Nightlies". The latter being encoded rather deeply between mozharness and its buildbot integration. Which yields the problems that you describe in your other post. It also seems to be the first thing that makes me wonder how I'd use mozharness locally to test if I broke l10n. Axel