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

[David Gobbi]

Can the gerrit dashboards do a temporary merge of the topic into the
current master, instead of just checking out the topic branch?

Something like this, perhaps implemented in the ctest script somehow:

git fetch origin master
git checkout -b merge-topic FETCH_HEAD
git merge topic
[ run dashboard ]

 - David


On Wed, Mar 6, 2013 at 3:36 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
> 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
>>
>>
> _______________________________________________
> 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
>