I've landed 8 new locales, all in one go in mozilla-central, and then pushed all 8 repos. Sadly, only nso and son got builds. Nick checked the db a bit, and there are at least, quote nthomas: so for nso rev 6142644b5b0 and en-ZA aa8d04e439 I see a row each in the changes table, but it's mapped into a single sourcestamp & buildset nthomas: since nso came slightly later that was what was built The pushes are on https://l10n-stage-sj.mozilla.org/pushes/l10n-central/?from=1282552557&until=1282557510, new locales are ak, br, bs, en-ZA, hy-AM, lg, nso, son, pushed in http://hg.mozilla.org/mozilla-central/rev/19ef853ea57c

Should 'nl' have been rebuilt at the time as well? I see builds in the db for this, but the logs have been purged already. For 'ak', a single sourcestamp was created with the following changes: mysql> select changes.comments, changes.revision from sourcestamp_changes, changes where sourcestampid=134950 and sourcestamp_changes.changeid = changes.changeid; +---------------------------------------------------------------------------------------+------------------------------------------+ | comments | revision | +---------------------------------------------------------------------------------------+------------------------------------------+ | http://hg.mozilla.org/l10n-central/ak/rev/8811de1cf13bd2723fa585222e218504cea7ccef | 8811de1cf13bd2723fa585222e218504cea7ccef | | http://hg.mozilla.org/l10n-central/ak/rev/a283daef8205c2afd10ba8e250bff07639414729 | a283daef8205c2afd10ba8e250bff07639414729 | | http://hg.mozilla.org/l10n-central/ak/rev/6917b7311c9fb6e8b966098cf1a28f990e2359cc | 6917b7311c9fb6e8b966098cf1a28f990e2359cc | | http://hg.mozilla.org/l10n-central/ak/rev/16d424edcbfbb60f6117dbe0afe9991106aa9380 | 16d424edcbfbb60f6117dbe0afe9991106aa9380 | | http://hg.mozilla.org/l10n-central/br/rev/114b2b440d285cb31fc84ef654776794cffb25aa | 114b2b440d285cb31fc84ef654776794cffb25aa | | http://hg.mozilla.org/l10n-central/br/rev/7f8370cba74f72227504cd31d393cbabee0dfa50 | 7f8370cba74f72227504cd31d393cbabee0dfa50 | | http://hg.mozilla.org/l10n-central/bs/rev/cacd9d9d71bd7f72d3e21bfb55ac6486d78431de | cacd9d9d71bd7f72d3e21bfb55ac6486d78431de | | http://hg.mozilla.org/l10n-central/bs/rev/c1d08b4f2c3acc98edfbc510ebd17569b958246f | c1d08b4f2c3acc98edfbc510ebd17569b958246f | | http://hg.mozilla.org/l10n-central/bs/rev/d202a6868865872ddb4be801b4f0172373e9da3d | d202a6868865872ddb4be801b4f0172373e9da3d | | http://hg.mozilla.org/l10n-central/en-ZA/rev/da42b2ac16c5d29e55db247a817c61565179d86a | da42b2ac16c5d29e55db247a817c61565179d86a | | http://hg.mozilla.org/l10n-central/lg/rev/33877df3383e9a8c049f776eafc7ef3f6fd02aa1 | 33877df3383e9a8c049f776eafc7ef3f6fd02aa1 | | http://hg.mozilla.org/l10n-central/lg/rev/08a54f7d1ac624a16de2d9962d5dacae9dad023c | 08a54f7d1ac624a16de2d9962d5dacae9dad023c | | http://hg.mozilla.org/l10n-central/lg/rev/be0ab97cc44f97299297129f54722c157f034041 | be0ab97cc44f97299297129f54722c157f034041 | | http://hg.mozilla.org/l10n-central/son/rev/d3cff877e097873bf226f29313b378b5bc4e9cae | d3cff877e097873bf226f29313b378b5bc4e9cae | | http://hg.mozilla.org/l10n-central/son/rev/d83a5d247c8c9903612c187ed4804f1706e43efb | d83a5d247c8c9903612c187ed4804f1706e43efb | | http://hg.mozilla.org/l10n-central/son/rev/1800776fd554fbdb15d39d884556c630bd041ff9 | 1800776fd554fbdb15d39d884556c630bd041ff9 | +---------------------------------------------------------------------------------------+------------------------------------------+

Verified that the l10n builders ARE included in the list of builders to not merge sourcestamps for, so the issue here is probably that the scheduler has a treeStableTimer != None, so is merging changes. Axel, any reason to have a treeStableTimer set for these repos?

I don't know anything about these scheduler anymore, as they're 0.8 codepath that you forked.

(In reply to comment #3) > I don't know anything about these scheduler anymore, as they're 0.8 codepath > that you forked. treeStableTimer is a regular buildbot scheduler parameter. It's currently set to 3 minutes, which basically means a 3 minute timer is started (or reset) every time a change arrives. When the timer expires, all collected changes are grouped up into a single sourcestamp and built. Setting it to None triggers a build request per change immediately.

You've been asking me for a reason why they're on, and I wouldn't know. That's independent of what they're technically doing.

(In reply to comment #5) > You've been asking me for a reason why they're on, and I wouldn't know. That's > independent of what they're technically doing. I'm asking you whether you feel you need this timer on or not. If you need it on (e.g. to push bustage fixes within the time window and not have a busted build), then we need to look at other ways to split out the changes. If you're ok with having it off, then say so.

The only reason for it to be on that I can see is to not overwrite tinderbox builds with revisions earlier in a push. I assume we're updating to default, though, so that's not an issue, other than wasting build cycles for multiple builds per push. So, I don't feel that we need a treeStableTimer on.

Comment on attachment 469949 [details] [diff] [review] Set l10n's treeStableTimer to None, and reduce poll interval to 5 minutes. changeset: 930:30499aa7f126

Landed this today. Have to wait until next time pushes happen to see if it's fixed for real.