[Insight-developers] Proposal: Should the September release just but a 4.2.1 patch?

Mon Jul 23 13:49:45 EDT 2012

I tend to agree with Matt McCormick's statements below.
Hans

--
Hans J. Johnson, Ph.D.
hans-johnson at uiowa.edu
Assistant Professor of Psychiatry
University of Iowa Carver College of Medicine
W278 GH, 200 Hawkins Drive

Iowa City, Iowa 52242
Phone:  319-353-8587

-----Original Message-----
From: Matt McCormick <matt.mccormick at kitware.com>
Date: Monday, July 23, 2012 12:08 PM
To: Bradley Lowekamp <blowekamp at mail.nih.gov>
Cc: ITK <insight-developers at itk.org>
Subject: Re: [Insight-developers] Proposal: Should the September release
just but a 4.2.1 patch?

On Mon, Jul 23, 2012 at 3:54 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Matt,
>
> Forgive me for not knowing but, why is keeping the minor release schedule
> important?

The regular minor release schedule is important for two reasons.
First, releases generate visibility and publicity for the project.
Second, contributors are encouraged by having their work released
often.

>
> In my view spending time to fix things that are not working to give the
> community that we are improving stability is important. Many discussion
>on
> patch releases vs minor releases, boil down to give the impression of
> stability or innovation.
>

Stability and innovation is not an either-or situation.  It is
possible to have both.

> From my personal usage, I would like a stable release version of ITKv4
> installed on some systems for some scientists to use. I don't think that
>4.2
> is it yet. And unfortunately its not uncommon, for a release to contain a
> couple of bug that require a patch or two. In some situation stability is
> good. While when I want the latest features I frequently can pick a
>specific
> commit near master, that is suitable.

ITK releases have been stable.  In areas they have not been stable, it
is a gap in the software processes.  We are now looking at performance
regressions and WrapITK issues.  Both of these have not been tested
well, and they are both broken.  We need a set of performance tests
and a method to monitor them.  WrapITK did not have a strong showing
on the nightly dashboard until recently, and there are not Gerrit
builds.   This explains why WrapITK is regularly broken by commits and
only works on a handful of platforms.

>
> Additionally, I don't think that both can really be done in the next 60
> days, so I suggested just doing the patch.

We need community involvement to support such a huge project.  Without
regular releases, we discourage community involvement.  People also
get the mindset of "I must merge this now, or it will be forever (6
months) before it is available."  This mindset does not help with
stability.

Matt

>
> Brad
>
>
> On Jul 23, 2012, at 11:25 AM, Matt McCormick wrote:
>
> Hi Brad,
>
> I think the performance issues and WrapITK issues are important enough
> to justify a patch release.  However, why substitute a minor release
> that has other feature improvements?  Keeping the minor release
> schedule regular is important.
>
> My 2 cents,
> Matt
>
> On Mon, Jul 23, 2012 at 1:55 PM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>
> Hello,
>
>
> I have been considering what is being discussed to be done between now
>and
>
> September, when currently the 4.3 release is scheduled, along with the
>
> resources that I am aware that are available to contribute and add new
>
> features to ITK. I would like to propose that we change the scheduled
>
> release in september to only a patch release of 4.2.
>
>
>
> The fix for the performance regression that Kent and myself have worked
>on
>
> in quite significant and there is still work to be done there to try to
>
> whittle the maximum number of GetInput calls down further. Additionally,
>
> there are some WrapITK issues I have encountered when I instantiate more
>
> pixel types. And there is the important patch that has been contributed
>by a
>
> use to get WrapITK working with VS10. So I think there is some
>significant
>
> fixes that would justify a 4.2.1 patch release.
>
>
>
> This would not disrupt those working on the forward progress of the
>master
>
> branch either. Those patches intended to be merged into the release can
>
> through the normal gerrit process. The only difference would be that
>should
>
> be based on the release branch and not the master branch, and SHOULD NOT
>be
>
> rebased before they are merged into master.
>
>
> Thanks for sharing you thoughts on this issue.
>
>
> Brad
>
>
>
> ========================================================
>
>
> Bradley Lowekamp
>
>
> Medical Science and Computing for
>
>
> Office of High Performance Computing and Communications
>
>
> National Library of Medicine
>
>
> blowekamp at mail.nih.gov
>
>
>
>
>
>
> _______________________________________________
>
> Powered by www.kitware.com
>
>
> Visit other Kitware open-source projects at
>
> http://www.kitware.com/opensource/opensource.html
>
>
> Kitware offers ITK Training Courses, for more information visit:
>
> http://kitware.com/products/protraining.php
>
>
> Please keep messages on-topic and check the ITK FAQ at:
>
> http://www.itk.org/Wiki/ITK_FAQ
>
>
> Follow this link to subscribe/unsubscribe:
>
> http://www.itk.org/mailman/listinfo/insight-developers
>
>
>
> ========================================================
>
> Bradley Lowekamp
>
> Medical Science and Computing for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov
>
>
>
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.itk.org/mailman/listinfo/insight-developers

________________________________
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.
________________________________