Github user ssimeonov commented on the issue:
https://github.com/apache/spark/pull/21589
@markhamstra I am confused about your API evaluation criteria.
You are not arguing about the specific benefits these changes can provide
immediately to an increasing majority of Spark users. Great.
You have some concerns about a minority audience of Spark users and you are
using those concerns to argue against immediate, simple and specific
improvements for the majority of Spark users. No problem, except that the
details of your concerns are rather fuzzy. Can you please make explicit the
specific harm you see in these APIs, as opposed to just arguing that there is a
theoretical, yet-to-be-defined-but-surely-just-right way to improve job
execution performance at an unspecified point in the future that will work well
for both majority and minority users?
BTW, the package argument is irrelevant here. Tons of things that are in
Spark can be done with Spark packages but, instead, we add them to the core
project because this increases the likelihood that they will benefit the most
users. The use cases discussed here are about essentially any type of job that
repartitions or coalesces, which clearly falls under the umbrella of
benefitting the most users.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
