Confirmed users, Bureaucrats and Sysops emeriti
2,976
edits
User:AxelHecht/Building l10n: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 91: | Line 91: | ||
''whenever you have to'' is another interesting question, I don't have a full answer to that. The goal would be "when there's a good reason to build this app for this locale". For the l10n side of things, this is involved, but with a clear answer. When a localizer checks in, build all products that that check-in affected. More on that below. | ''whenever you have to'' is another interesting question, I don't have a full answer to that. The goal would be "when there's a good reason to build this app for this locale". For the l10n side of things, this is involved, but with a clear answer. When a localizer checks in, build all products that that check-in affected. More on that below. | ||
For en-US, things are more confuzzled in my head. Let's take a check-in to /cvsroot. That may or may not affect localization, if it does, it would impact all locales for all apps that include that localizable string. Butt. At the time of that check-in, there's no build with that change yet. I think there's some value in running compare-locales at the point, but it's not uber-big. I guess for en-US, we really need to figure out which builds we want to repackage, and what their source is. Right now, firefox nightlies would be good again, for an actively evolving line of development, being more agile is key. Like, if localizers only have 24 hours to fix a late-l10n issue, we shouldn't wait for the next nightly to tell them. Not sure how much horse power a full repack run on each nightly would take, and for how many products we want to cough that up. Right now, linux cycles around 1.5 hours on l10n, dep en-US builds are around 4 per hour. Just doing a full compare-locales run is a lot quicker, though. Maybe compare-locales tip against tip, and l10n-merge against the time-stamped source. | For en-US, things are more confuzzled in my head. Let's take a check-in to /cvsroot. That may or may not affect localization, if it does, it would impact all locales for all apps that include that localizable string. Butt. At the time of that check-in, there's no build with that change yet. I think there's some value in running compare-locales at the point, but it's not uber-big. I guess for en-US, we really need to figure out which builds we want to repackage, and what their source is. Right now, firefox nightlies would be good again, for an actively evolving line of development, being more agile is key. Like, if localizers only have 24 hours to fix a late-l10n issue, we shouldn't wait for the next nightly to tell them. Not sure how much horse power a full repack run on each nightly would take, and for how many products we want to cough that up. Right now, linux cycles around 1.5 hours on l10n, dep en-US builds are around 4 per hour. Just doing a full compare-locales run is a lot quicker, though. Maybe compare-locales tip against tip, and l10n-merge against the time-stamped source of the build. | ||
=== Lessons learned === | |||
Here is a list of things that I tried and that didn't work out very well | |||
==== builder per build ==== | |||
Creating one builder per locale and app and platform doesn't scale. It's not really helpful in watching the waterfall, and, as there are naturally tons of builders per slave, it raises a bunch of interesting load balancing problems. | |||
; resolved : I use build properties to denote application, locale, and tree (branch combo, set of locales) | |||
==== Scheduler.fileIsImportant ==== | |||
fileIsImportant sounds like a cool idea to only build l10n-impact changes, but it leaves all non-important files in the changeset, which, once you're master is pulling /cvsroot and /l10n on separate branches, is just evil. | |||
=== Current arch on l10n.m.o === | |||
Right now, I'm running a bonsai poller per branch and rep, so, as I'm only running trunk for l10n right now, two bonsai pollers. There is a single scheduler, which is using helper objects (''Dispatcher'') to map those changes to tree/application/locale tuples to be built. | |||
Then the scheduler submits non-mergeable build requests, which the respective builders (linux-langpack only for now) pick up. They then ask the Scheduler which tree/application/locale is actually pending. That way I work around the lack of custom build properties. That's implemented by a specific Build class, and that's communicating those settings back down to the steps by setting those as build properties, too. | |||
; drawback : The build queue is now state of the Scheduler, which doesn't persist state. Thus, no reconfig. | |||
=== Outlook === | |||
In this scheme, application and locale and such are only available as build properties, that is, finding the latest 15 German builds is hillariously costly in standard buildbot. Thus I added a status plugin that stores state in a real database. I intend to extend that to match buildbot better, and then use that database to actually persist the status of pending builds, so the scheduler can go dumb again, and things would be restart and reconfig friendly. | |||