FCS Quality All the Time
By mkupfer on Aug 10, 2006
As one might expect, working with the external community on OpenSolaris is a bit of a learning experience, for both the people who work for Sun and the people who don't. Differences in goals, assumptions, and so on lead to different ways of doing things. One difference that I've seen pop up recently has to do with ON's policy of "FCS Quality All the Time" (aka Production Ready All the Time).
Ideally, we'd like the ON master gate to be good enough that if someone told us to cut a release tomorrow, we'd be happy to do it. In reality, there are usually showstopper bugs that need to be fixed before we could cut a release.
So what does "FCS Quality All the Time" mean for developers?
One thing that it means is that bugs that break the build, or which make the code sufficiently unusable, must either be fixed quickly (within hours), or the gatekeeper will back out the change that introduced the problem.
Another thing that it means--and this is what I want to focus on here--is that it's not acceptable to put something into the gate with known showstopper bugs. You can't say "yeah I know it's broken, but I promise to fix it before the release closes".
There are a couple reasons for this. One reason is to avoid a Quality Death Spiral. The other reason is to avoid a firedrill at the end of the release, where you have a bunch of deferred stoppers to fix. What happens in this situation, almost always, is that everyone has to put in extra time and the release is delayed. It's stressful, and because a lot of fixes are going in at the last minute, the final quality is probably worse than it would have been if the fixes had gone in earlier.
Notice I said a "bunch" of bugs. If the policy is that it's okay to putback with known stoppers, then it's okay for everyone, not just your project. And with a 100 putbacks going into each build, that just doesn't scale.
A common reason for wanting to putback early is to give the code more exposure. While more exposure will help quality, it's better for project teams to make binaries available on their web site. These can be packages, BFU archives, or tarballs. It's potentially a little more work for the project team, but doing it this way is a win for the community as a whole.
So if you catch yourself thinking "it's okay, I'll just putback the fix later", be sure to ask yourself: is it okay enough to ship it as it is? If it is, great. If it's not, fix it before you putback. Everyone will thank you for it.
 This is also why we require architectural approval prior to putback.