[
https://issues.apache.org/jira/browse/SPARK-34427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284504#comment-17284504
]
L. C. Hsieh commented on SPARK-34427:
-------------------------------------
Sigh...do you ever see that I say I want to ignore SPARK-10816 in my previous
comments? Do I say I don't want to consider the existing effort? I just said
(you can look at previous comments, it is unchanged):
> From the code size, that (yours) PR is much larger than another. I'm not sure
> if from feature perspective they are the same. As it comes to the weekend, I
> can take another look at the previous two PRs.
> From my side, I'd like to push this feature as we have real use case and
> requirement. But I'm not sure if we want to follow up with previous PRs.
I am not aware of SPARK-10816 when I created this JIRA with assignee. That's
all. I don't know why this JIRA irritates you so much.
What I did is NOT that I created this SPARK-34427, then see there is an
existing SPARK-10816, then I immediately assign SPARK-34427 or SPARK-10816 to
myself to occupy the issue and prevent others working on it...
The assignee works like a placholder to notify others the issue is ongoing work
or a work on plan. It is not strict and as you did, it can be easier removed or
changed. If I don't set it, then other folks might think it is open issue and
put some efforts on working on it. That is so called not to step on others toes.
Once we figure out from communication with all parties what is best way to have
an implementation for the feature, we can definitely change the assignee.
I cannot accept your point to explain this assignee case is different. If I am
going to assign SPARK-10816 to myself, then it is not acceptable. But I just
created a new JIRA we plan to do with assignee. I don't know what is wrong with
this usual practice. So sorry, but your point doesn't make sense to me. It is
also not what I saw in past years and now in the Spark community.
I guess you are unhappy here as I assigned this JIRA because you was working on
it, and you think I occupy it. But again, when I created this JIRA with
assignee, I don't know there is SPARK-10816 and you worked on it before. I
don't mean to occupy the work you have worked on it. Is it clear to you?
I don't really want to continue this argument. It is meaningless to me and
waste my weekend time. Let me to be clear again:
I created this JIRA with assignee because we plan to have this feature. Setting
assignee is to prevent others (especially the contributors who are not familiar
with Spark community) accidentally think it is open and put their time working
on it.
We will respect existing efforts. I did not know there is existing SPARK-10816.
I need take some time to look at the existing works (they are both big change).
Note that there is not only one implementation even in SPARK-10816, and I don't
see any cooperation between two implementations. We can have communication
between all parties involved and see what is the best way to have the feature.
I will like to focus on real work instead of arguing this stuff. If you are
interested in continuing pushing the session window. I think I need some time
taking look the details of design and code in SPARK-10816 and think how to have
the feature in best shape.
> Session window support in SS
> ----------------------------
>
> Key: SPARK-34427
> URL: https://issues.apache.org/jira/browse/SPARK-34427
> Project: Spark
> Issue Type: New Feature
> Components: Structured Streaming
> Affects Versions: 3.2.0
> Reporter: L. C. Hsieh
> Priority: Major
>
> Currently structured streaming supports two kinds of windows: tumbling window
> and sliding window. Another useful window function is session window. Which
> is not supported by SS. We have user requirement to use session window. We'd
> like to have this support in the upstream.
> About session window, there is some info:
> https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/operators/windows.html#session-windows.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
