(Credit to Luke Kanies for this idea, it was something he mentioned briefly in a panel discussion on config management at LISA 2007.)

The idea behind controlled deployment of etch changes was to give the humans (NOC, SA team, etc.) time to notice widespread failures as changes propagate through the environment and activate the killswitch or fix the problem before the bad change propagates to all of production.

However, as etch clients are reporting their success or failure back to a central location (which also happens to be the place where we keep the killswitch), we could examine that data and make a pretty good guess as to whether there is a bad change propagating through the environment. If a significant percentage of the systems in a given controlled deployment class go from good to failed (or don't report in at all) in a given hour we should assume something not good is happening and activate the killswitch automatically.

Moved from https://sourceforge.net/apps/trac/etch/ticket/3