Platform support policy proposal

There is a fair amount of confusion about the specific operating system platforms, platform versions, etc. that Chef Software, Inc. supports for its products. This RFC will clarify this by calling out the individual operating systems and their releases as explicitly supported or not.
"tier 1 platforms should have some sort of post-build verification, because we've gotten burned in the past"

Right, I disagree.

* OEL/RHEL/CentOS should be "Tier1" in terms of what we tell customers.
* I do not want and do not think we need testers for more than one of those.

We have largely *NOT* gotten burned in the past on OEL or RHEL when compared to CentOS, so comparing it to Solaris is largely apples and oranges.  Clearly based on the Solaris-specific code in the client and on past history we need testers there in order to validate.  I haven't seen the same errors on the RHEL-variants.  Even in the one error I can think of in the past year (the postrm script issues) that turned up in Amazon Linux, not in OEL/CentOS/RHEL.

So, I think you're making up a rule here which will have very little value and will have a large amount of cost (at least 6 testers per distro, if not 12 testers per distro).  The expansion of the test matrix produces instability, even just instability in jenkins (I just had a chef-client-build run fail because jenkins dropped in the middle of it a few minutes ago).  The more boxes there are in the matrix then the more failures we are going to have.  I seriously doubt our ability to engineer an infrastructure where we get intermittent test failures down to zero, I think that's about as likely as ever getting a drug-free society.  Likewise, we do not need to drive distro-specific bug fixes to zero.  Just because we have a metric doesn't mean there isn't an acceptable risk of failures to escape CI testing.  At some point the cost of trying to mitigate the last few failures exceeds the cost of just living with fixing those bugs after they are released.