On 15 August 2012 23:40, Eric Niebler <eric@boostpro.com> wrote:
I don't have a fundamental issue with shipping a release with known bugs. In fact, I don't think boost has ever gone out the door without heaps (no pun intended) of known bugs -- just check trac. Taking a fix is taking a risk. You could break something more fundamental, maybe on a platform you don't have access to, or maybe in a downstream library you didn't test locally. Some bugs are serious enough to justify the risk this late in the cycle. Most are not. That's why we have our release policies in place. IMO, it's not too onerous to require that testers have had a chance to cycle on changes in trunk before they get merged to release. It's a low bar. If somebody wants the release managers to make an exception for a particularly serious bug, they can make their case.
If a bug is considered serious enough, we should delay the release by a few days, rather than rush the fix. The problem is that everyone considers their bug to be particularly serious, and bug reports keep coming in. We need to balance that value of that fix against the cost of delaying the fixes that ready for release. The tests seem to be running more frequently recently (esp. on windows), which does make it easier to get things in on time. Btw. if anyone has a patch that doesn't make it, I can add it to the release notes as I did for unordered in 1.50. I'm not sure if anyone made use of it, but at least it was published.