[vtk-developers] Adding VTKData and VTKLargeData as optional submodules

[Berk Geveci]

I agree with everyone :-)

I am also behind the ExternalData solution but we simply don't have
the cycles to implement it right now. I am going to slightly disagree
with the "work well enough" statement though. If you look at the
dashboard today, many of the Gerrit builds have failures in them due
to regression image changes. I had the same problem during hack-a-ton
: I couldn't get a single clean Gerrit dashboard because I had
branched from before a regression change. It was very annoying.

Maybe we should suggest to folks that they need to rebase their topics
more often to avoid these failure then? What does that do to Gerrit
topics?

PS: I dislike submodules as much as the next person.

-berk


On Wed, Mar 6, 2013 at 2:39 PM, David Cole <dlrdave at aol.com> wrote:
> I know I’m late, but I’ll chime in now.
>
> I agree with Bill L. here: why bother with an interim “solution”.
>
> It’s just busy work.
>
> It works “well enough” right now without anybody having to do anything.
>
> Leave well enough alone until the ExternalData approach can be implemented.
>
>
>
> From: Marcus D. Hanwell
> Sent: March 6, 2013 1:47 PM
> To: Bill Lorensen
> CC: VTK Developers
> Subject: Re: [vtk-developers] Adding VTKData and VTKLargeData as optional
> submodules
>
> I will leave that to Berk, I was clarifying what was actually being
> suggested. I listed pros/cons as we saw them, such as once I merge in
> a topic that changes the baseline all topics branched from an earlier
> master will begin to fail for no particular reason. This may or may
> not be that much of an issue.
>
> Once we have the time then I (and I believe Berk) am totally behind
> moving to the external data solution, which is superior to this
> approach and seems to have had most of the kinks worked out by now.
>
> Marcus
>
> On Wed, Mar 6, 2013 at 1:39 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>> My last comments.
>>
>> Why bother with an interim solution? Why not wait until the ITK solution
>> can
>> be made.
>>
>> The sub-module approach will require some change in process which will
>> eventually be replaced with another change in process.
>>
>> One good thing about the current approach. It gives a reviewer a chance to
>> see the changes in the output intorduced by a topic. For example, in a
>> recent gerrit topic, I was able to comment that the new images looked
>> worse
>> than the original.
>>
>> Bill
>>
>>
>> On Wed, Mar 6, 2013 at 1:29 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>>
>>> On Wed, Mar 6, 2013 at 10:47 AM, Jean-Christophe Fillion-Robin
>>> <jchris.fillionr at kitware.com> wrote:
>>> > Hi Marcus,
>>> >
>>> > Since by default, it seems the ExternalProjects CMake module is doing a
>>> > recursive update on sub-modules, how would these VTK sub-modules be
>>> > considered as optional in that case ?
>>> >
>>> > See
>>> >
>>> >
>>> > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/ExternalProject.cmake;h=bf2892b741e0d5551ecd310c461289a09e214cf6;hb=HEAD#l318
>>>
>>> External project could be modified not to do that, and having them
>>> there is unlikely to hurt things (but would increase time to
>>> checkout).
>>> >
>>> > When building project that depends on VTK, we can not assume VTK will
>>> > be
>>> > built with testing enabled.
>>>
>>> We are not, and external project is one possible way of obtaining VTK
>>> that could easily be modified.
>>> >
>>> > Instead wouldn't it make more sens to generalize what ITK folks are
>>> > doing to
>>> > make its easy to reuse for other projects ?
>>> >
>>> I don't know how much clearer I can be, I said in the original post
>>> that after discussing this with Berk we agree that external data is
>>> the way to go long term but he doesn't feel that we have the
>>> time/resources (correct me if I am wrong Berk) to do that at this
>>> time. This was suggested as a possible interim solution - we are well
>>> aware of the ITK/CMake external data solution.
>>>
>>> Marcus
>>
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>