Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at