The names of the machines are: - l10n-linux-tbox - l10n-win32-tbox - bm-xserve12

To clarify, we won't be shutting these down until we've had a full week of side-by-side builds with the new system. That would bring us to Wednesday next week (Oct 8).

(In reply to comment #1) > To clarify, we won't be shutting these down until we've had a full week of > side-by-side builds with the new system. That would bring us to Wednesday next > week (Oct 8). Sorry I missed this, its long past 08oct2008. Is it ok to proceed with deleting these slaves, or should we hold off a little longer?

Given that the new 1.9.0 l10n machines were off for nearly a week I feel like we should wait until we have a full week without a problem like that :).

(In reply to comment #3) > Given that the new 1.9.0 l10n machines were off for nearly a week I feel like > we should wait until we have a full week without a problem like that :). They were already up for slightly over a month, since 01oct2008, and only down for the last week because of the FF304 release. I'm totally happy to leave them running longer if that removes any lingering concerns - how much longer would you like?

(In reply to comment #4) > (In reply to comment #3) > > Given that the new 1.9.0 l10n machines were off for nearly a week I feel like > > we should wait until we have a full week without a problem like that :). > > They were already up for slightly over a month, since 01oct2008, and only down > for the last week because of the FF304 release. I'm totally happy to leave them > running longer if that removes any lingering concerns - how much longer would > you like? Gentle ping... any reason to keep these systems still running?

Yeah, we're probably OK to shut them off now. It _might_ be nice to wait until we know we don't have to turn them off for a release - but about:rights is fully translated for Fx3.0 now - so there probably won't be other string changes in the near future.

I'd rather not turn these off until we verify that the replacement new l10n systems are up and running correctly, so we could do releases, nightlies, etc. In that context, is there anything left to do before we powerdown these machines?

For releases, we do it in the slaves from the production-1.9 pool. These old machines are not used at all For nightly and dependents: - I have just checked "l10n-linux-tbox": /builds/tinderbox/Fx-Trunk-l10n/tinderbox-configs/tinder-config.pl $ftp_path = "/home/ftp/pub/firefox/nightly/old-l10n"; $url_path = "http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/old-l10n"; $tbox_ftp_path = "/home/ftp/pub/firefox/tinderbox-builds"; $tbox_url_path = "http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds" $BuildTree = 'MozillaTest'; These slaves are reporting to "MozillaTest" (not even MozillaStaging as I thought): http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaTest&maxdate=1225846901&legend=0&norules=1 and pushing to: * http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/old-l10n/ * http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/bm-xserve08-mozilla1.9.0/ (even though the slave is bm-xserver12) * http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/fx-linux-tbox-mozilla1.9.0/ * I do not know where the win32 slaves are pushing Regarding if anybody is using these machines to look at the compare-locales log iIf you look at one of the logs: * http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1225845442.1225847584.15408.gz&fulltext=1 You will find something like this for all of the locales "af...success" between "the 3 dots" and "success" an email has been sent to "MozillaTest-af" which is a tinderbox page that do not exist and therefore nobody actually can see the run of compare-locales If there is any localizer looking at compare-locales, it is through the l10n dashboard or their local runs but not any of these logs This has been like this since the beginning of October. Please feel free to stop these slaves any time

Yeah, I agree with Armen here. Chris suggested pausing them for awhile before deleting them - can we do that today?

Until bug#467196 is fixed, the l10n tbox machines listed in comment#0 are the only machines producing l10n repacks for FF3.0, so these should not be turned off until bug#467196 is fixed.

(In reply to comment #10) > Until bug#467196 is fixed, the l10n tbox machines listed in comment#0 are the > only machines producing l10n repacks for FF3.0, so these should not be turned > off until bug#467196 is fixed. Now that bug#467196 is completed, does anyone need these machines anymore? Does the new l10n process running on 1.9.0 do everything as good/better then what these 3 old l10n machines used to do? Its only safe to delete them once we know the machines are no longer needed for anything, hence asking for re-confirm!

Last change - I'm planning to delete these machines next week unless there's a reason to keep them around...

I've now powered off these machines: - l10n-linux-tbox - l10n-win32-tbox - bm-xserve12 After a couple of days waiting to see if anyone had anything unadvertised running there, I'll delete the VMs and reimage the xserve.

(In reply to comment #13) > I've now powered off these machines: > - l10n-linux-tbox > - l10n-win32-tbox > - bm-xserve12 > > After a couple of days waiting to see if anyone had anything unadvertised > running there, I'll delete the VMs and reimage the xserve. ok, from last minute checks with axel and coop, there's nothing here to backup, so I've now deleted l10n-linux-tbox and l10n-win32-tbox VMs. Bug#474544 is tracking the project of deciding what is best use of bm-xserve12, and then reimaging bm-xserve12 as appropriate. Nothing left to do in this bug, so closing this as FIXED.