eagle wrote:
Bruce, have you done time in bug-jail?
Do they let you play XBOX games in there?
We play PC based Halo on the IE team

And my team doesn't usually have bug jail. Let me explain:
The quality gates allow for a certain number of open bugs to be carried by a team, based on their number of developers. If your team is passed that number, you can't RI. In other words, your product / feature / feature set is deemed "too buggy" to be moved up the branch tree into WinMain.
The purpose behind this fixed number ("bug cap") is to prevent a team from working for a long time on features without fixing bugs, until an unsolvably huge pile of bugs have been pushed forward month after month. Or at least unsolvable without a death march + slip + minor miracle at the endgame (hmmm, been there, done that, don't like it).
A team is required to meet that number when the team wants to RI. You can exceed that number all you want, but you have to be under bug cap to RI. And you have to RI your features according to the master schedule - no working off to the side in your own little off-the-books world and unveiling everything in one massive RI.
In practice, that means you have to be pretty near bug cap all that time, or you'll have a mess to solve come RI time, and maybe you'll solve it and maybe you won't, and that will be even a worse mess.
One way to stay near bug cap is to not let devs exceed it, ever - that's bug jail. If a dev has too many bugs, then he/she can't work on other stuff and has to go fix those bugs until he/she is back under their allotment. Some teams do it that way.
Another way is the more traditional "code the first part of the milestone, fix bugs the end, plan to get under bug cap in front of the RI" approach. My UX team does it this way. It's riskier, because the trick is calculating when to switch from coding to fixing, how many features to implement, predicting your glidepath to RI, etc. We have lots of glidepath discussions ...