systemml-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luciano Resende <luckbr1...@gmail.com>
Subject Re: Release cadence
Date Mon, 06 Mar 2017 18:14:26 GMT
+1 for SystemML 1.0 as the next release.

On Sat, Mar 4, 2017 at 10:23 AM, Deron Eriksson <deroneriksson@gmail.com>
wrote:

> Personally I would like the next release to be 1.0. We have been an
> incubator project since November 2015 and I believe that after over 1,000
> commits since then that the project is about ready for a 1.0 release.
>
> I agree with Matthias that we need to make a decision regarding this topic.
> For new issues and fixed issues in JIRA, we need to be able to assign the
> correct version, or else someone potentially needs to go through and fix
> the version numbers, as Glenn has been doing. Additionally, it would be
> nice to do some of the 1.0 code updates (such as removing the old
> MLContext) now rather than waiting additional months. Also I would like to
> be able to correctly identify our next version in the online documentation.
>
>
How about just make SystemML Next and change the release name when we do
the release ?



> Deron
>
>
> On Sat, Mar 4, 2017 at 12:47 AM, Matthias Boehm <mboehm7@googlemail.com>
> wrote:
>
> > thanks Arvind for bringing some structure to the release process. I
> think a
> > fixed cadence of 2 months is useful as it makes upcoming releases more
> > predictable for devs and users.
> >
> > However, we're discussing a major 1.0 release for a while now. I think it
> > would be useful to come to an agreement if we go for 1.0 in April or not.
> > There are some pending changes such as removing the old MLContext,
> removing
> > the file-based transform, isolating the matrix block library, and some
> > language changes that should only be addresses in a major release as they
> > break backwards compatibility. Right now, we can't touch these changes
> > without knowing the target release.
> >
> > Personally, I don't see a good reason why we should wait. Postponing this
> > major release just creates unnecessary overhead in maintaining these old
> > components that will be removed eventually. Since we cut RC for 0.13 on
> Feb
> > 20, I think having an RC around April 20 would be a good target for this
> > 1.0 release.
> >
> >
> > Regards,
> > Matthias
> >
> >
> > On Fri, Mar 3, 2017 at 5:44 PM, Arvind Surve <acs_s@yahoo.com.invalid>
> > wrote:
> >
> > > 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 <acs_s@yahoo.com.INVALID>
> > >  To: "dev@systemml.incubator.apache.org" <dev@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 <reinwald@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 <deroneriksson@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, <dusenberrymw@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 <luckbr1975@gmail.com>
> > > > wrote:
> > > > >
> > > > > On Thu, Jan 5, 2017 at 6:05 AM, Matthias Boehm
> > > <mboehm7@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/
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
> --
> Deron Eriksson
> Spark Technology Center
> http://www.spark.tc/
>



-- 
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message