In addition to the issues mentioned above, Wenchen and Xiao have flagged
two other regressions (https://issues.apache.org/jira/browse/SPARK-23316
and https://issues.apache.org/jira/browse/SPARK-23388) that were merged
after RC3 was cut.
Due to these, this vote fails. I'll follow-up with an RC4 in
I agree that this is not a blocker against RC3. It was not appropriate as a
vote for RC3.
There is no problem if it is in time for release 2.3.0.
--
Sent from: http://apache-spark-developers-list.1001551.n3.nabble.com/
-
To
I agree that SPARK-23413 should be considered a blocker. It isn't
unreasonable to run a history server that is used for several versions of
Spark.
On Thu, Feb 15, 2018 at 7:49 AM, Sean Owen wrote:
> SPARK-23381 is probably not a blocker IMHO; it's a nice-to-have to make
> some
Hi all,
I've created a new JIRA.
https://issues.apache.org/jira/browse/SPARK-23437
All concerned are welcome to discuss.
Best,
Valeriy.
On Sat, Feb 3, 2018 at 9:24 PM, Valeriy Avanesov wrote:
> Hi,
>
> no, I don't thing we should actually compute the n \times n matrix.
SPARK-23381 is probably not a blocker IMHO; it's a nice-to-have to make
some returned values match an external implementation, for code that hasn't
been published yet.
However I think it's OK to add to the 2.3.0 release if there's going to be
another RC.
On Wed, Feb 14, 2018 at 10:49 PM Holden
Thanks for the reply @srowen.
>>I don't think you can move or alter the class APis.
Agreed. That's not my intention at all.
>>There also isn't much value in copying the code. Maybe there are
opportunities for moving some internal code.
There will probably be some copying and moving internal
I don't think you can move or alter the class APis. There also isn't much
value in copying the code. Maybe there are opportunities for moving some
internal code. But in general I think all this has to wait.
On Thu, Feb 15, 2018, 5:17 AM Yacine Mazari wrote:
> Hi,
>
> I see
Since it seems there are other issues to fix, I raised SPARK-23413 to
blocker status to avoid having to change the disk format of history
data in a minor release.
On Wed, Feb 14, 2018 at 11:06 PM, Nick Pentreath
wrote:
> -1 for me as we elevated
Hi,
I see that many classes under "org.apache.spark.ml" are still referring to
the "org.apache.spark.mllib" implementation.
While there still is time until the deprecation deadline by version 3.0,
having these dependencies makes it impossible or difficult to make
improvements to these classes.