I spent way too much typing this reply. I should just join the freebsd development team and learn the answer to my own question. Thinking about this again - ya

I spent way too much typing this reply. I should just join the freebsd development team and learn the answer to my own question. Thinking about this again - yah - the poster might be referring to some kind of workflow like this: production machines are platforms that run -STABLE there is some kind of device, embedded or otherwise, that they keep locked up somewhere in a lab. It could be the new xxyz multicore switching fabric [imaginary name] that is running a new version of BSD-OS variant that's undergoing verification testing - they run hardware development and need -CURRENT's capabilities for debugging the system itself. It generates some keys that will be distributed into the pool of machines running -STABLE so that in the future, when this new variant comes into the market, there will be "pre-seeded" keys for compatability (ie. older versions of systems will be able to interact via signed certs with the new system) Since FreeBSD is BSD licensed, there can be any number of things people are doing with it without anyone else knowing - so maybe to give the benefit of the doubt, I can envision a workflow that needs -CURRENT as a workstation / dev platform. I think one weakness to my thinking is that VARIANTS/WITNESS/kdb/ddb can be enabled on -RELEASE and -STABLE distributions as well! Why not just do everything on -STABLE even if you need kernel debugging? If they need -CURRENT for new hardware support, it shouldn't be too hard to figure out from the svn log and the rolling release notes. It's kinda fun trying to reverse engineer the job of the thread parent's acquaintance!