Currently, we generate l10n repackages every 4 hours for Firefox3.0 as if it they were nightly builds even if there have been no changes. We could build on change by use some of the work that Axel has on: http://hg.mozilla.org/users/axel_mozilla.com/tooling/file/b4a8228e90ab/buildbot-configs/l10n/master.cfg#l53 54 bp = BonsaiPoller('http://bonsai-l10n.mozilla.org', 'all', 'HEAD', 55 cvsroot='/l10n', pollInterval = 5*30) 56 c['change_source'].append(bp) 57 58 ep = BonsaiPoller('http://bonsai.mozilla.org', 'PhoenixTinderbox', 'HEAD', 59 cvsroot='/cvsroot', pollInterval = 5*30) 60 c['change_source'].append(ep)

We'll likely backport the fix from bug 464163.

Not enough check-in traffic to merit this. Will continue to work on bug 464163.

Reopening, a decision like that actually needs a real discussion.

The release team *had* a real discussion about this. If you're still targeting new locales for the 3.0 branch, there might be some merit here, otherwise focusing on 3.1/m-c makes more sense to us. But we can discuss at the l10n meeting.

I think I've got the kinks worked out here. We set things up differently (slaves builder names, etc.) on 3.0 than m-c/1.9.1, but I've tried to move the 3.0 system a little closer to m-c to minimize the config delta in the future. I have this running on staging-1.9-master. It's pointing at the live CVS server for en-US changes, but at a local CVS mirror for l10n. I'm going to try pushing to one of the local l10n repos now, and 3.0 "nightlies" are scheduled to trigger in about an hour.

To avoid having to setup bonsai, I've filed bug 482382 to get stgbld access to the l10n CVS repository.

Now that stgbld has access, staging-1.9-master has been reconfig-ed to point to the real l10n CVS repo, including bonsai.

We're getting nightlies just fine, but there's not much check-in traffic for l10n on 3.0 right now. Axel says he has a few pending approvals that need to land by next week. That should be enough to test the dispatchers, but if they don't fire, we may need to revisit the decision not to setup bonsai on staging.

Gonna hit some approvals today.

Armen's going to take over the monitoring of this. He's made some changes to the master.cfg->adding/uncommenting the missing poller. We'll let it run over the weekend in staging with the hope of landing the config changes early next week.

The commit from bug 464542 has been caught by the bonsai poller and triggered the repackages of the locale 'te'. The only steps that failed were the "upload packages" since in staging-stage if a folder is not modified for the last X days it gets removed and therefore /home/ftp/pub/mozilla.org/firefox/nightly/latest-mozilla1.9.0-l10n/ did not exist. I have created the missing folder in staging-stage. I will attach the patch for review on Monday The logs appear in tinderbox's MozillaStaging page: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaStaging/1237126812.1237126858.8365.gz&fulltext=1 http://tinderbox.mozilla.org/showlog.cgi?log=MozillaStaging/1237126812.1237126854.8356.gz&fulltext=1 http://tinderbox.mozilla.org/showlog.cgi?log=MozillaStaging/1237126812.1237127037.8981.gz&fulltext=1 NOTE: The builder names do not match what is on production-1.9 - To be fixed

Awesome. Thanks for keeping an eye on this, Armen.

I will work on the production patch when this review is reviewed positively.

Comment on attachment 367820 [details] [diff] [review] master.cfg and l10nbuilds.ini - enable locale repackage on change for staging-1.9 There is a new parameter passed to the scheduler from changes in bug 482270. Sorry for the previous review request. I will upload the correct patches tonight when I get home.

(In reply to comment #15) > (From update of attachment 367820 [details] [diff] [review]) > There is a new parameter passed to the scheduler from changes in bug 482270. > Sorry for the previous review request. I will upload the correct patches > tonight when I get home. Can we fix the builder names at the same time, if possible?

I am not asking for review even though this would work but I need to know what to do with the parameter "factory" which is now mandatory (http://hg.mozilla.org/build/buildbotcustom/file/tip/l10n.py#l845). In my patch I pass 'linux' which is one of the allowed platforms. Another workaround would be to follow the for loop for builders used in mozilla2. We don't really need the parameter for nightly repackages nor for repackages on change since we look at the all-locales file which has no platform specified to build on. I would do some refactoring on the __init__ method of L10nMixin to pass only two mandatory parameters: repoType (cvs or hg) and buildType (nightly or release) and then a third parameter kwargs. Depending on the combinations of repoType and buildType we would do different assertions and look for different keys on kwargs. Unfortunately this would require restesting of the nightly and the release scenarios to see if nothing fails after the refactoring. I should have known better when I was writing that code *sigh* l10n_nightly_scheduler = NightlyL10n( name='nightly', -#have l10n repackages every 4 hours and -#leave a gap for the en-US builds that happens at 5AM -#until we have en-US builds driven by buildbot - hour=[1,9,13,17,21], + # leave a gap of 4 hours from the en-US builds that happen at 5AM + hour=[9], builderNames=[ - 'linux_l10n_nightly', - 'win32_l10n_nightly', - 'macosx_l10n_nightly', + 'Firefox cvs-1.9.0 linux-i686', + 'Firefox cvs-1.9.0 win32', + 'Firefox cvs-1.9.0 mac', ], repoType='cvs', cvsRoot=cvsroot, + # give any accepted platform even though we don't need it + platform='linux' # You can specify your own list of locales # locales=['af','en-GB','de'] )

(In reply to comment #16) > (In reply to comment #15) > > (From update of attachment 367820 [details] [diff] [review] [details]) > > There is a new parameter passed to the scheduler from changes in bug 482270. > > Sorry for the previous review request. I will upload the correct patches > > tonight when I get home. > > Can we fix the builder names at the same time, if possible? Builder names fixed according to production-1.9/master.cfg

(In reply to comment #17) > (http://hg.mozilla.org/build/buildbotcustom/file/tip/l10n.py#l845). In my patch > I pass 'linux' which is one of the allowed platforms. No longer necessary after recent buildbotcustom patches. An updated patch is running on staging-1.9 right now and seems to be working. I'm going to try to create a comparable patch for production this afternoon.

(In reply to comment #19) > No longer necessary after recent buildbotcustom patches. An updated patch is > running on staging-1.9 right now and seems to be working. Scratch that. The buildbotcustom version was from Axel's repo.

I gave this a quick whirl on production-1.9-master this afternoon just to make sure it would work with the current buildbotcustom tip. The patch also does some cleanup work, putting slave info into a separate file (like m-c/1.9.1).

Comment on attachment 370967 [details] [diff] [review] Changes to production-1.9 master to do repack on change. It is good. Can you please add this comment: + # give any accepted platform even though we don't need it before the following line until we don't need this parameter?: + platform='linux', Since coop will be off next week I will ask someone to commit it for us and I will take care of reconfiguring production-1.9

Both staging and production masters for 1.9 have been updated now.