[IGSTK-Developers] Sandbox decoupling

[David Gobbi]

I know that I'm entering this discussion a little bit late, but I think
that it would be very nice if there was some way to have an
on/off option in CMake for coupling the sandbox to the main
repository.

It is very nice sometimes to have the ability to duplicate a file
from the main repository, and then share the development of
new features for that file with other people before deciding
whether those features should go to the main repository.

So if there is a way that we can maintain this feature but have
it turned off by default, that would be the best.  We could have
some dashboard machines running it one way, and other machines
running it the other way to make sure that it is properly tested.

The whole point of the sandbox is that new features should be
fully tested and reviewed before going to the main repository.
That means that any time we want to make significant changes
to IGSTK classes, we have to copy them to the sandbox
until the changes are tested and reviewed.   It is written in
our requirements that new features must be sandboxed
before the requirements are finalized so that the changes
can be committed to the main repository:
http://public.kitware.com/IGSTKWIKI/index.php/Requirements_Process

So if we decouple the sandbox, that means that we are
agreeing to freeze all the classes in the main repository,
so that only bug fixes or minor enhancements to those
classes are allowed, but restructuring of those classes
won't be possible.

 - David


Luis Ibanez wrote:
>
> Hi Julien,
>
> I would discourage the practice of commenting out lines, both in C++
> files and in CMakeLists.txt files.
>
> If we need to recover something later, then we can use CVS to recover
> older versions. That's after all one of the great benefits of using
> CVS.  Commenting out lines is not a mechanism that we can maintain
> over the years. That is, two years from now, nobody will know exactly
> why those lines are commented out, and whether they should be removed
> or restored. If restored they probably will not work anymore because
> the rest of the toolkit would have evolved and the lines may not even
> match the syntax of the CMake 4.5 that we presumably will have in two
> years.
>
>
> During code reviews we should systematically delete lines of code that
> are commented out. They can only lead to confusion.
>
>
> If we feel that we are dealing with an option to be used sometimes,
> then we should fully configure it as an option that is turned ON/OFF
> from CMake.
>
>
> I would suggest that we simply remove the mechanism from the
> CMakeLists.txt file of the Sandbox and when commiting this change
> back to CVS we use a very clear and detailed description of what the
> change means.  It can even be worth to tag both repositories in order
> to signal this significant change. That will make even easier to get
> back to this state if we ever find that necessary.
>
>
>
>   Luis
>
>
>
> --------------------
> Julien Jomier wrote:
>> I agree too.
>> If we can just comment out the mechanism instead of deleting it that 
>> might be useful in case we need it in the future.
>>
>> Julien
>>
>> Andinet Enquobahrie wrote:
>>
>>> Hi Luis,
>>>
>>> I agree with you 100%.
>>>
>>> -Andinet
>>>
>>>>
>>>> Now that we are wrapping up the main developing effort,
>>>> it seems to be a good time for decoupling the Sandbox
>>>> from the main IGSTK library.
>>>>
>>>> We are still using the system that merges IGSTK into
>>>> the Sandbox and test everything combined as if the
>>>> Sandbox were absorbing all the code.
>>>>
>>>> This approach was used during the period we were refactoring
>>>> IGSTK classes and brought them to the Sandbox in order to
>>>> accelerate the process.
>>>>
>>>> The same model doesn't seem to be maintainable for the next
>>>> stage of the toolkit, which is probably a smoother and more
>>>> incremental evolution of the classes.
>>>>
>>>> We could remove the mechanism that copies all the files from
>>>> the main library into a sandbox directory, and simply build
>>>> the Sandbox as a external project based on IGSTK. In this
>>>> more normal scenario there will be no duplication of code
>>>> between the main IGSTK and the Sandbox.
>>>>
>>>>
>>>> Please let us know if you see any drawback in proceeding
>>>> with this clean up.
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>   Thanks
>>>>
>>>>
>>>>      Luis
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> IGSTK-Developers mailing list
>>>> IGSTK-Developers at public.kitware.com
>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> IGSTK-Developers mailing list
>>> IGSTK-Developers at public.kitware.com
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>
>>
>>
>>
>
>
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>