FW: [Insight-developers] Build Errors: AffineTransform, MRASlabIdentifier,GibbsPriorFilter, QuaternionRigid

[Luis Ibanez]

Bill,

The refactoring of the RegistrationTransforms was a major change,
it involved more than 70 files, and some changes in the
RegistrationFramework. It took more than a week from the
introduction of the first modifications until the dashboad was stable
again.  The error caused by the absent itkQuaternionTransform class
is the remanent of about a thousand errors produced in the first days.
So from a wide perspective this remanent error is probably not that bad.

The files where checked in before the re-factoring was finished
because is quite hard to ensure that the new versions will be
acceptable on all our platforms, and the Dashboard is the best
(and maybe the only) way to verify this consitency.

Thanks to checking in the partial re-factoring, incompatibilities
between SGI/WinNT/gcc where detected early in some of the transforms
before the same changes were done in the rest of them, and even
with that help, several iterations where required to get a combination
that satisfied all the compilers.

I agree with the rule that things should be fixed rapidly, but
with refactoring is not easy to anticipate how long it will
take to get rid of all the errors.

The rigid transform will still pass through a couple of changes, and
they will affect all the registration methods in the toolkit.

I like your proposal of automatically receiving mail for errors we
introduce in the Dashboard, it will be a great help in getting rid of
errors in a rapid way.


Luis,


--------------------


These files where checked in before finishin
On Wed, 15 Aug 2001, Bill Hoffman wrote:

> Ok, but why do files get "checked in" before the re-factoring
> is finished?  The system should not be in a state where it does
> not compile for TWO WEEKS!   I just went back in the dashboards,
> and it has been 14 days since someone could cvs checkout Insight
> and build with no syntax errors.
>
>  From time to time, it is necessary to check-in half completed work,
> (need to test it on another machine, need to have others fix up code
> after a re-work of some part of the system.)
> but as a rule of thumb it should be fixed up enough so that it at least
> compiles within a day.
>
> We can not have a system that is broken for weeks at a time.   When the
> system is like this, new errors get checked in, because people get used
> to a red dashboard.
>
> -Bill

-- 
Luis Ibanez                                      CB#:   7060
Research Assistan Professor                      phone: (919) 843 5436
Division of Neurosurgery                         fax:   (919) 966 6627
University of North Carolina at Chapel Hill      email: ibanez@cs.unc.edu
Chapel Hill, NC 27599-7060                       http://www.cs.unc.edu/~ibanez