[Insight-developers] PLEASE *DO NOT* COMMIT CHANGES TO ITK BRANCHES

[Luis Ibanez]

Mathieu,


1)  Who requested this backporting to the ITK 3.4 branch ?

     Where is the bug entry in the MANTIS bug tracker ?

     If we are talking about:

        0005173: ITKConfig.cmake should not export SOURCE DIR
        http://public.kitware.com/Bug/view.php?id=5173

     This not a bug assigned to the ITK 3.4 branch.



2)  Adding/removing lines of code without submitting builds
     to the Dashboard is *experimenting*.

     In particular, the changes:
http://www.itk.org/cgi-bin/viewcvs.cgi/ITKConfig.cmake.in?root=Insight&only_with_tag=ITK-3-4&r2=1.20.2.1&r1=1.20

     Can only be tested by

       1) Building ITK with ITK_LEGACY_REMOVE OFF,
       2) Then installing ITK
       3) Building an application that uses ITK_SOURCE_DIR,
          against that installed ITK.


     There is no such submission in the Dashboard.
     Therefore, we don't even have a proof that these
     lines actually work.

     In fact,

         Bill Hoffman's rule holds true once again:

            Anything that is NOT Tested IS Broken.


     These lines *do not work*, because ITK_LEGACY_REMOVE has *never*
     been defined in ITK. The first definition of this CMake variable
     was added to the main CMakeLists.txt file just seven days ago
     in the CVS HEAD:

http://www.itk.org/cgi-bin/viewcvs.cgi/CMakeLists.txt?root=Insight&r1=1.271&r2=1.272

     These definition never existed in ITK 3.4 nor previous releases.

     The work of copying the VTK legacy macros into ITK was half done
     and we were using the macros in some places without having defined
     the CMake variables to control them.




3)  CVS write access to any Open Source project is a privilege.

     The fact that you do it in your free time without being paid
     is quite nice indeed, and we appreciate it very much.

     We all do many things in our free time, and do not get paid
     for many of them. That doesn't mean the we are excluded from
     having to follow the rules of technical quality defined by
     the community.



4)  You are right that we should use an automated method for
     enforcing the control of commits to branches. These events
     demonstrate that setting verbal rules is not sufficient,
     and that is not effective.




         Luis



-----------------------
Mathieu Malaterre wrote:
> On 10/21/07, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> 
>>          Branches are *not* the place
>>          to experiment with code changes.
> 
> ...
> 
>>CVS write access has now been removed for the two recent
>>offenders. (They know who they are).
> 
> 
> Well let's give names... I am one of them. I have done the
> backporting, from a request from someone from kitware (I think he
> knows who is he is). This was a bug fix which I thought was already on
> the 3.4, so by re-adding it I do not think I was 'experimenting' with
> code change (since this line of code was added ~ITK 2.8).
> 
> I work on ITK on my free time, yes I do not get paid for my work on
> the toolkit and I do try to do my best every time I commit something.
> And no I did not do it on purpose to break the '4 years' rules to not
> commit on a branch. Kitware is already using a script to control
> commit to a branch, so this is not even a technical challenge that ITK
> is not reusing the same script.
> 
>