From: David Abrahams (dave_at_[hidden])
Date: 2004-06-28 17:13:15
"Aaron W. LaFramboise" <aaronrabiddog51_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk