Re: Release cadence

[Arvind Surve <ac...@yahoo.com.INVALID>]

Based on last couple of release cycles, we will continue with 2 months release cycles.We will do first RC build by end of first week of second month.
We will plan on releasing next release by end of April 2017.We will have RC build on ~April 6th.  -Arvind
Arvind Surve | Spark Technology Center  | http://www.spark.tc/

      From: Acs S <ac...@yahoo.com.INVALID>
 To: "dev@systemml.incubator.apache.org" <de...@systemml.incubator.apache.org> 
 Sent: Monday, January 9, 2017 11:41 AM
 Subject: Re: Release cadence
   
We need to release SystemML on more frequent basis to get community engaged. It will provide us more feedback on functionality we add.While releasing SystemML on monthly basis is challenge due to longer phase of validation process we need to find a way to be quicker.
I can propose options to get closer to monthly release if acceptable.
Make every two releases available on monthly basis and third on two months basis. This cycle will continue.
1. Do minimal testing on two releases (minor releases) and release them on monthly basis. Performance testing is one of the major time consuming activity especially for larger data size. We can limit testing only upto 80GB. We can do code freeze (other than fixes) at the end of third week and do verification on last week. If we find any issues we can still release the code with limitation documented unless issue breaks major functionality.2. Do comprehensive testing on third release.   This will include performance testing for all data size and every other testing we do. We can do code freeze (other than fixes) at the end of third week and start verification of code. All issues found will be addressed. Exception will be considered.

Meantime we need to start automating testing pieces.

Arvind SurveSpark Technology Centerhttp://www.spark.tc/

      From: Berthold Reinwald <re...@us.ibm.com>
 To: dev@systemml.incubator.apache.org 
 Sent: Saturday, January 7, 2017 1:35 AM
 Subject: Re: Release cadence
  
I think that a 2 month cycle would be a good compromise for major/minor 
releases. Fixpack release could be at a 1 month cycle.


Regards,
Berthold Reinwald
IBM Almaden Research Center
office: (408) 927 2208; T/L: 457 2208
e-mail: reinwald@us.ibm.com



From:  Deron Eriksson <de...@gmail.com>
To:    dev@systemml.incubator.apache.org
Date:  01/05/2017 02:14 PM
Subject:        Re: Release cadence



+1 for trying out a 1 month release cycle.

However, I highly agree with Matthias that there is a lot of overhead with
releases, so it would be good if we can work to streamline/automate the
process as much as possible. Also, it would be good to distribute the 
tasks
around as much as possible. This can result in cross-training and help
avoid overburdening the same contributors each month.

If the overhead slows us down too much, then we can go to a slower release
cycle.

Deron




On Thu, Jan 5, 2017 at 1:50 PM, <du...@gmail.com> wrote:

> +1 for adopting a 1 month release cycle.
>
> --
>
> Mike Dusenberry
> GitHub: github.com/dusenberrymw
> LinkedIn: linkedin.com/in/mikedusenberry
>
> Sent from my iPhone.
>
>
> > On Jan 5, 2017, at 1:35 PM, Luciano Resende <lu...@gmail.com>
> wrote:
> >
> > On Thu, Jan 5, 2017 at 6:05 AM, Matthias Boehm 
<mb...@googlemail.com>
> > wrote:
> >
> >> In general, I like the idea of aiming for consistent release cycles.
> >> However, every month is just too much, at least for me. There is a
> >> considerable overhead associated with each release for end-to-end
> >> performance tests, tests on different environments, code freeze for 
new
> >> features, etc. Hence, a too short release cycle would not be "agile" 
but
> >> would actually slow us down. From my perspective, a realistic release
> >> cadence would be 2-3 months, maybe a bit more for major releases.
> >>
> >>
> > 2-3 months of release cadence for an open source is probably a long
> > stretch, particular for a project that does not have very large set of
> 3rd
> > party dependencies.
> >
> > As for some of the overhead issues you mentioned, they are probably 
easy
> to
> > workaround:
> >
> > - code-freeze timeframe can be resolved with branches
> > - end-to-end performance regressions can be avoided by better code
> review,
> > and if you were willing to go with 2-3 months without performing these
> > tests, we could perform them only for major releases, and proactively
> > quickly build a minor release with the patch when a user report any
> > performance regression.
> >
> >
> > Anyway, I would really like to see SystemML more agile with regards to
> its
> > release process because, as I mentioned before, the release early,
> release
> > often mantra is good to increase community interest, generate more
> traffic
> > to the list as developers discuss the roadmap and release blockers, 
and
> > also enable users to provide feedback sooner on the areas we are
> developing.
> >
> >
> >
> > --
> > Luciano Resende
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
>



-- 
Deron Eriksson
Spark Technology Center
http://www.spark.tc/