I would agree to most of the part except that there would be need to have
SystemML support on Spark 2.0 for "Spark As A Service" (or DSX). I haven't seen
formal request for Spark 2.0 support from SAAS/DSX team yet, but I heard they
are targeting 09/30. In such situation, I would like to prioritize SystemML
support on Spark 2.0 around same time as 0.11 release.
-Arvind
From: Glenn Weidner <gweid...@us.ibm.com>
To: dev@systemml.incubator.apache.org
Sent: Monday, September 19, 2016 10:07 PM
Subject: Re: [DISCUSS] SystemML releases 0.11 and 1.0
+1
Thanks,
Glenn
Berthold Reinwald---09/19/2016 09:52:26 PM---+1. I'd even consider not fixing
old MLContext releated issues.
From: Berthold Reinwald/Almaden/IBM@IBMUS
To: dev@systemml.incubator.apache.org
Date: 09/19/2016 09:52 PM
Subject: Re: [DISCUSS] SystemML releases 0.11 and 1.0
+1.
I'd even consider not fixing old MLContext releated issues.
Regards,
Berthold Reinwald
IBM Almaden Research Center
office: (408) 927 2208; T/L: 457 2208
e-mail: reinw...@us.ibm.com
From: Matthias Boehm/Almaden/IBM@IBMUS
To: dev <dev@systemml.incubator.apache.org>
Date: 09/19/2016 08:21 PM
Subject: [DISCUSS] SystemML releases 0.11 and 1.0
Hi all,
we already discussed and agreed that it would be good to make our next
release relatively soon. However, there was also a discussion around
making
the major 1.0 release but this would require substantially more time
because it is our opportunity to remove APIs and cleanup the language.
I'd like to propose the following: let's release a 0.11 release in the
next
couple of weeks, targeting at Spark 1.x including the old and new
MLContext
APIs as well as both file-based and frame-based transform. Subsequently,
we
can focus on our major 1.0 release, including the support for Spark 2.x,
the removal of the old MLContext API, and the removal of the file-based
transform functionalities. Hopefully we get compression and GPU support
into production-ready state until the 1.0 release too.
The next step would be to collect open issues for the 0.11 release. From
my
perspective, this should mostly center around documentation, robustness
and
performance of the new MLContext API and frame support as well as the
simplification of our build process.
Regards,
Matthias
