"Aaron W. LaFramboise" <aaronrabiddog51@aaronwl.com> writes:
Almost everything is the regression tests. The idea is, that if your changes pass the regression test, everything that worked before should still work. What might have problems would be new features that don't have tests, or odd bugs that noone has written tests for, etc.
There is a certain amount of civic responsibility here. The idea is that a submitter is responsible for his patch. If a patch breaks something, even if its only by exposing a latent bug, the submitter has an obligation to help the maintainer of the broken area to fix it. It's my opinion that this works well in practice.
This isn't a new idea for Boost: that's the way we've always operated. The difference is probably that GCC has a nice automatic regression test system. Several people have been working on setting that up for Boost, but it's not done yet.
I personally beleive its very important that the main tree should always be working, even if it is "unstable" simply due to its sheer volatility. If patches are allowed to be checked in that cause regressions, and the submitter is not obligated to fix the problems created by the introduction of the patch, there is no particular garentee that it will be fixed at all in a timely manner. If parts of the project are broken for extended periods of time, development work might be dramatically slowed or halted altogether.
It's never been OK to leave things in a broken state. IMO the one possible exception is a new library that nothing depends on and is not yet officially released. It might be OK to allow that library to be "broken" while the maintainer works on porting issues. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com