I think no vote is needed. The pull request is actually converging towards
a decision.
On Thu, Aug 18, 2016 at 12:07 PM, Robert Metzger
wrote:
> I forgot to start the VOTE after 24 hours.
> However, I checked again Apache's voting rules [1] and code changes require
> consensus. So a -1 vote by a
I forgot to start the VOTE after 24 hours.
However, I checked again Apache's voting rules [1] and code changes require
consensus. So a -1 vote by a PMC member effectively is a veto.
I don't have the impression from the discussion that we have a clear
majority for one approach, so a VOTE thread woul
I would like have a decision on this so that we can merge the pull request.
If we can not come up with a solution everybody agrees, and nobody rejects
the VOTE, I'll start a VOTE thread in 24 hours.
On Tue, Aug 9, 2016 at 3:57 PM, Till Rohrmann wrote:
> That is a tough call but I'm personally
That is a tough call but I'm personally leaning slightly towards not
breaking the API and adding a note for the casting workaround.
My main concern is where do we set the limit for future API breaking
issues? How critical does an issue has to be to be allowed to break the
API? Currently, we have 1
I agree that expecting users to cast is undesirable. Upon changing the API,
why would we not mark the next release as 2.0?
The same issue arose with Gabor's addition of hash-combine in the Scala
DataSet API where DataSet was returned rather than a specialized Operator.
The solution was to add an o
As an user, I don’t like “casting option”. Because people who need set
parallelism after CoGroup will certainly fall into this issue. They will
subconsciously think Flink does not support this feature. We can’t assume most
users will read JavaDocs and document carefully.
Maybe we can post this
Thank you for bringing this discussion to the mailing list.
I agree with Chesnay's comment on GitHub that we should consider the
"casting option" as well. I don't think we should break the API if there is
a (admittedly ugly) work-around for those who run into the problem.
If we put the work-around
Hi all!
We have a problem in the *DataStream API* around Windows for *CoGroup* and
*Join*.
These operations currently do not allow to set a parallelism, which is a
pretty heavy problem.
To fix it properly, we need to change the return types of the coGroup() and
join() operations, which *breaks th
