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

[Matt McCormick]

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