[Insight-developers] ITK 3 tag to use with slicer? Fwd: Slicer release schedule

[Johnson, Hans J]

All,

I'm sorry, but this has grown well beyond what I originally agreed to do.
I had originally agreed to help get the very simple (and probably very
safe) 3 line patch set that provided missing standard header definitions
that were claimed to make ITKv3 build under gcc4.6.

Here is what I have, but it does not compile with gcc4.6 on mac due to an
unrelated problem:

git fetch origin
git checkout v3.20.0
git remote add slicer https://github.com/Slicer/ITK.git

git cherry-pick d2a5e977c67df0849add

git cherry-pick 9208c459776ee7635857

I am sorry that I will not be able to take this any further.  There are
too many items on my ITKv4 list that must be addressed.


Hans


On 7/17/11 7:25 AM, "Stephen Aylward" <stephen.aylward at kitware.com> wrote:

>Hi JC,
>
>To accomplish the goal of having this ITKv3 release be the release
>used for Slicer requires your 64-bit modifications to be included
>(that you discuss below), right?
>
>Also, good catch on the IO framework changes.   They are backward
>compatible (i.e., they offer significant IO speedup without breaking
>the API), and the speedup is also very important to Slicer - these
>changes should also be included in the release.
>
>Thanks!
>Stephen
>
>
>
>On Sat, Jul 16, 2011 at 8:16 PM, Jean-Christophe Fillion-Robin
><jchris.fillionr at kitware.com> wrote:
>> Bill,
>>
>> If this hasn't been fixed already, would be great to integrate the
>>following
>> patches also:
>>
>> 1) To compile ITK 3.20 on 64bits windows
>>
>> Merge branch 'fix-vnl-64bits-compile' into slicer-4.0
>>
>> * fix-vnl-64bits-compile:
>>   Review DETERMINE_TYPE vxl macro
>>   Add VXL_SIZEOF_SIZE_T test
>>   Add VXL_HAS_WIN_WCHAR_T test
>>
>>   Update VXL_HAS_TYPE_OF_SIZE test
>>
>>
>>
>> See
>>
>>https://github.com/Slicer/ITK/commit/71e4277a785ae0f14c5c1cd2a8df1a70d99f
>>1052
>>
>>
>> Stephen,
>>
>> 2) What should we do regarding the following commits:
>>
>> Merge branch 'reader-speedup-reuse-buffer' into HEAD
>>
>> See
>>
>>https://github.com/Slicer/ITK/commit/5ec3d26e2d5533cb06f7fd0801593e16b77a
>>2c96
>>
>> and
>>
>> Merge branch 'MetaIOUpdate' into slicer-4.0
>>
>> See
>>
>>https://github.com/Slicer/ITK/commit/9a6954f7a278fc010551980c8413cecb5c48
>>ea62
>>
>>
>>
>> Regarding the MetaUIUpdate, would it be possible to add a flag /
>>property so
>> that:
>>   - people using ITK 3.20 could then benefit from your improvement
>>   - backward compatibility is maintained
>>
>> Thanks
>> Jc
>>
>> On Sat, Jul 16, 2011 at 6:03 PM, Stephen Aylward
>> <stephen.aylward at kitware.com> wrote:
>>>
>>> Hi Luis,
>>>
>>> Thanks for the reminder!
>>>
>>> Transparency, openness, and community involvement are key to ITK.
>>>
>>> What are the typical steps when considering backporting changes to an
>>>old
>>> version of itk?
>>>
>>> S
>>>
>>> On Jul 16, 2011 11:34 AM, "Luis Ibanez" <luis.ibanez at kitware.com>
>>>wrote:
>>> > On Sat, Jul 16, 2011 at 10:33 AM, Stephen Aylward
>>> > <stephen.aylward at kitware.com> wrote:
>>> >> I guess we could propose that itk-slicer become the next itk3
>>>release,
>>> >> but
>>> >> it would probably have to be funded by na-mic.
>>> >>
>>> >> Perhaps Hans as Pres and Bill as CTO of the ISC should decide?
>>> >>
>>> > ---------------------------------------------------------------------
>>> >
>>> > I'm disappointed to have to remind this group that
>>> > this is *NOT* how Open Source communities operate.
>>> >
>>> > Decisions that involve the entire community are *NOT*
>>> > to be made by a couple of members of hierarchical
>>> > organization, not even the ISC.
>>> >
>>> >
>>> > ITK is not a Corporation.
>>> >
>>> > It is an Open Source project.
>>> >
>>> >
>>> > Changes are to be proposed to the community and
>>> > to be voted upon using the grassroots governance
>>> > structure that is already in place.
>>> >
>>> > Backroom negotiations are poisonous for an
>>> > Open Source projects. They send the signal to
>>> > developers that no matter how much sweet and
>>> > blood they put into the project, at the end we have
>>> > not respect for their opinion when it comes to making
>>> > important decisions that affect the entire project.
>>> >
>>> > It is *NOT* the role of the ISC to decide on the content
>>> > of an ITK release. That is up to the developers team
>>> > to decide.
>>> >
>>> >
>>> > Please:
>>> >
>>> >
>>> > A) Make this discussion public in the ITK developers list.
>>> > B) Put a proposal in an ITK Wiki page.
>>> > C) Explain the technical rationale for the proposal
>>> > D) Gather feedback from the community
>>> > E) Reach consensus
>>> > F) Execute
>>> >
>>> >
>>> > The day when ITK software decisions will be made by
>>> > a bureaucratic minority, that will be a great day to Fork.
>>> >
>>> >
>>> > Luis
>>
>>
>>
>> --
>> +1 919 869 8849
>>
>>
>
>
>
>--
>
>==============================
>Stephen R. Aylward, Ph.D.
>Director of Medical Imaging Research
>Kitware, Inc. - North Carolina Office
>http://www.kitware.com
>stephen.aylward (Skype)
>(919) 969-6990 x300



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________