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

[Bill Lorensen]

We should also make sure that the changes in itk 3.21 make their way
into ITKv4. Many probably already have.

Bill

On Sun, Jul 17, 2011 at 9:44 AM, Stephen Aylward
<stephen.aylward at kitware.com> wrote:
> Hi Hans,
>
> I fully agree this shouldn't be on you.
>
> This is needed for Slicer, so na-mic should do this.  It is for slicer3, so
> I am not certain who should do it.  Right now just learning the scope of
> work that is needed.
>
> I kind of just expected itk-slicer to become itk3.21 instead of any
> cherrypicking.  Seems easiest and will directly accomplish the goals.
>
> S
>
> On Jul 17, 2011 9:04 AM, "Johnson, Hans J" <hans-johnson at uiowa.edu> wrote:
>> 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.
>> ________________________________
>