Taking a recent try build as an example we do the following useful sendchanges (master, branch): production-master01.build.mozilla.org:9009, try-win32-talos talos-master.mozilla.org:9010, try-win32-talos (Tiger talos) production-master01.build.mozilla.org:9009, try-win32-opt-unittest geriatric-master.build.mozilla.org:9989, try-win32-opt-unittest And the following bogus sendchanges: staging-master.build.mozilla.org:9009, try-win32-talos staging-master.build.mozilla.org:9009, try-win32-opt-unittest talos-staging-master02.build.mozilla.org:9012, try-win32-talos Those two masters have gone away because the move to preproduction + personal masters, and talos-staging-master02 outliving its usefulness. The sendchanges fail out quickly (2 seconds) because they can't open the port, but we should still clean up.

Well, the talos-staging-master02 VM got deleted today, so it's a stretch to say it's outliving anything!

English is a strange language, 'tis true! This should do the trick, but I should take the patch for a spin on a master before asking for review.

I have fixed up staging-master:9009. I am not sure if it was stopped intentionally or not.

Do we have a plan for what is happening to the staging buildbot scheduler-db after switching over to dev-master ?

I don't know. I got frustrated when talos-staging-master02 was shut off without a proper plan for what to do with the scheduler. A tool to create sendchanges was proposed but nothing on stone.

Bug 656413 has a reviewed patch to accomplish this, see attachment 540821 [details] [diff] [review].