[Insight-developers] Backward Compatibility

Tue May 13 08:12:31 EDT 2008

Stephen,

I agree. This would also allow us to test the impact more thoroughly.
Another alternative would be to #ifdef the centered pixel option.

Yet another consideration, I think VTK has the same issue when it
internally converts coordinates.

Bill

On Tue, May 13, 2008 at 7:30 AM, Stephen Aylward
<Stephen.Aylward at kitware.com> wrote:
> I was referring to his comments on Bug:
> # 0006558 (http://www.itk.org/Bug/view.php?id=6558)
>
> Sorry if there was confusion.
>
> Stephen
>
> On Tue, May 13, 2008 at 7:29 AM, Stephen Aylward
> <Stephen.Aylward at kitware.com> wrote:
>> This may be a situation where we create a new function that performs
>>  the operation correctly, and we begin to deprecate the old function.
>>
>>  It is highly likely that someone in the world has also discovered this
>>  feature and developed a work-around in their code.  If we change it,
>>  we will break their code, i.e., WE will create a bug in their code
>>  that would be extremely difficult for them to detect and potentially
>>  critical to the output they produce.
>>
>>  The new function name should be more explicit of the operation it performs:
>>
>>  TransformPhysicalPointToCenteredIndex   ?
>>  TransformPhysicalPointToRoundedIndex ?
>>
>>  etc
>>
>>  That's my suggestion.
>>
>>  Stephen
>>
>>
>>
>>  On Tue, May 13, 2008 at 5:16 AM, Andreas Keil <andreas.keil at cs.tum.edu> wrote:
>>  > Dear ITK developers,
>>  >
>>  >  triggered by the "adopt a bug program" - I consider getting more involved
>>  >  in ITK. For this reason, I kindly ask you to point me to ITK's backward
>>  >  compatibility policy. So far, I found the sources mentioned at
>>  >  http://www.itk.org/Wiki/ITK_Policies_and_Procedures which tell me that
>>  >  this issue is still an open discussion. I am still wondering how strictly
>>  >  backward compatibility is enforced, i.e. in which cases backward
>>  >  compatibility is allowed to be broken. (I mean, there must be cases where
>>  >  it may be broken, e.g. when fixing severe bugs.)
>>  >  I am specifically wondering about the following two bugs I reported:
>>  >
>>  >  # 0004560 (http://www.itk.org/Bug/view.php?id=4560)
>>  >  Here, I would vote for reopening the issue and throwing exceptions
>>  >  whenever one of the Set... methods is called with the parameter i out of
>>  >  bounds. Throwing an error here would not really change ITK's behaviour. It
>>  >  would only change the exception handling which is anyways only performed
>>  >  in case a user used the class incorrectly. If I were such a user, I would
>>  >  be glad to have a changed behaviour here, wouldn't I?
>>  >
>>  >  # 0006558 (http://www.itk.org/Bug/view.php?id=6558)
>>  >  In the case of this so far unattended but IMHO really severe bug, every
>>  >  fix would change behaviour since the current implementation is plain
>>  >  wrong. I would have volunteered to work on a fix. However, I don't feel
>>  >  experienced enough to work on this bug which is located in the heart of
>>  >  ITK - the ImageBase class, esp. since it requires changing ITK's
>>  >  behaviour.
>>  >
>>  >  Looking forward to your comments,
>>  >  Andreas.
>>  >
>>  >
>>  >
>>  >  -----Original Message-----
>>  >  From: insight-users-bounces at itk.org [mailto:insight-users-bounces at itk.org]
>>  >  On Behalf Of Luis Ibanez
>>  >  Sent: Thursday, May 08, 2008 04:25
>>  >  To: Insight Users
>>  >  Subject: [Insight-users] PROGRAM ANNOUNCEMENT: "ADOPT A BUG"
>>  >
>>  >
>>  >
>>  >
>>  >             Our bugs are feeling sad and lonely
>>  >                   due to lack of attention.
>>  >
>>  >
>>  >
>>  >
>>  >          We have decided to give them out for adoption.
>>  >
>>  >
>>  >
>>  >
>>  >             Join now the "Adopt a Bug" program,
>>  >                 and help us make ITK a more
>>  >                 useful and reliable toolkit.
>>  >
>>  >
>>  >
>>  >
>>  >  As you probably have heard from recent posts to the mailing list,
>>  >  ITK is in need of a *bug purification campaign*. We have a collection
>>  >  of bugs that have been lingering for quite a while, and some of
>>  >  them even have fixes proposed by the bug reporters.
>>  >
>>  >
>>  >  In order to tackle this challenge, we would like to engage the
>>  >  *collective intelligence* of the users community.
>>  >
>>  >
>>  >  One of the strongest assets of Open Source is the enormous potential of
>>  >  the large number of users that can make small localized contributions.
>>  >
>>  >  The cumulative effect of those contributions can not possibly be matched
>>  >  by a traditional organization. There is no way that the developers team
>>  >  could ever compete with the aggregated brain power of more than 1500
>>  >  well-educated users currently subscribed to the mailing list.
>>  >
>>  >
>>  >
>>  >  We are looking for courageous users willing to contribute some hours
>>  >  of their time to ensure that our bugs receive the care that they
>>  >  deserve.
>>  >
>>  >
>>  >
>>  >  By adopting any of our dearest 257 open bugs, you will commit to
>>  >  take the steps needed for making sure that your adopted bug gets
>>  >  fixed before the release of ITK 3.8.
>>  >
>>  >
>>  >
>>  >  We care about our bugs and therefore we will not simply give them
>>  >  away to strangers. Bug adoptive parents should satisfy the following
>>  >  requirements:
>>  >
>>  >
>>  >      1) Have good C++ skills
>>  >
>>  >
>>  >      2) Adhere to the Dashboard quality practices
>>  >
>>  >
>>  >      3) Subscribe to the following strong parental attitude:
>>  >
>>  >            "If you guys don't fix it, I will fix it"
>>  >
>>  >
>>  >      4) Respect the backward compatibility policy
>>  >
>>  >
>>  >
>>  >
>>  >  As a participant in the "Adopt a Bug" program you will receive CVS write
>>  >  access to the ITK repository and you will be entitled to commit bug
>>  >  fixes by yourself. You will be encouraged to work with other developers
>>  >  in finding consensus on the best way to fix a bug.
>>  >
>>  >
>>  >
>>  >  As ITK users you probably will be interested in a particular bug
>>  >  that may be making difficult for you to get your project done.
>>  >  That one will probably be the best bug for you to adopt since you
>>  >  will be directly interested in getting that bug fixed as soon
>>  >  as possible.
>>  >
>>  >
>>  >
>>  >         Please join the "Adopt a Bug" program today
>>  >         and help make ITK a better place to program.
>>  >
>>  >         Pick your Bug now at:
>>  >
>>  >                http://public.kitware.com/Bug
>>  >
>>  >
>>  >         and send us email so that we can take care
>>  >         of the adoption paperwork.
>>  >
>>  >
>>  >
>>  >
>>  >    Thanks
>>  >
>>  >
>>  >       Luis
>>  >
>>  >  _______________________________________________
>>  >  Insight-developers mailing list
>>  >  Insight-developers at itk.org
>>  >  http://www.itk.org/mailman/listinfo/insight-developers
>>  >
>>
>>
>>
>>  --
>>  Stephen R. Aylward, Ph.D.
>>  Chief Medical Scientist
>>  Kitware, Inc. - Chapel Hill Office
>>  http://www.kitware.com
>>  (518) 371-3971 x300
>>
>
>
>
> --
> Stephen R. Aylward, Ph.D.
> Chief Medical Scientist
> Kitware, Inc. - Chapel Hill Office
> http://www.kitware.com
> (518) 371-3971 x300
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>