Re: [boost] Re: 1.32 release preparation

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-06-28 16:32:05

David Abrahams wrote:

> "Aaron W. LaFramboise" <aaronrabiddog51_at_[hidden]> writes:
>>>I think they are willing to destabilize the main trunk at least
>>>during stage 1.
>>
>>It's worth pointing out that actual breakage itself is never allowed.
>>All patches must pass regression testing before they can be committed,
>>even in Stage 1.  Very rarely is a patch accepted which causes a
>>regression or other failure.  Also, it is never ever acceptable for a
>>patch to be committed that breaks bootstrap or some other major
>>functionality, as seems to happen occasionally with Boost, as this
>>prevents actual work or testing from happening.
>>
>>The previous sorts of broken code are what branches are for.
>>
>>The destablization allowed in stage 1 is primarily code which passes the
>>regression tests, but is so large or intrusive that there are almost
>>certainly unknown significant bugs or unforeseen problems.
>
> So what's in the regression tests?  Do they test every single compiler
> back-end?  Do they have one of every target machine?  It seems to me
> that changes in the intermediate language or even some front-ends
> might be very difficult to make if they have to keep every host/target
> combination working.  IIUC, people who maintain ports to various
> targets are domain experts much like the maintainers of various
> "higher-level" boost libraries.

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.

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.

On the other hand, theres a lot of momentum to get new features out
there and integrated.  Branches work very well for this.  In GCC, there
are several branches that depend on other branches, all for
functionality that is eventually going to make it into mainline (after
it works!!).  Everyone gets to work on their code without fear that
someone else might break it and temporarily halt their work, and
everyone is happy.

Aaron W. LaFramboise