Re: Getting a Tier-X for localized builds. X=1

On 21 January 2016 at 05:37, Mike Hommey <[email protected]> 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.
>


I'm not sure what you mean by this. This is how l10n repacks happen
generally right now* - they are triggered after nightly builds finish, and
consume the nightly builds as input. The problem (as I see it) is that this
pretty much happens *only* for nightly builds, which makes it impossible to
test on try or catch bustage on inbound.

Cheers,
Chris

* we also do l10n repacks whenever one of the l10n repositories change -
but I'm not sure if those valuable to consider for this discussion?