Hi Alex, As I replied in the FLINK-28046, I don't think it's fair to resolve the migration complexity issues after marking them deprecated, because that would practically shorten the migration period. But that can be discussed.
Given that eliminating the removal of SourceFunction was proposed 10 days ago, and a 2nd round of VOTE [1] was just started, I'd suggest not to further block the VOTE on this topic. How about this, we continue with the vote as is, and keep the discussion on the SourceFunction in Jira or a separate thread. Once the discussion is finalized, and if we decide to add the item back, we start another VOTE to update the must-have item list. WDYT? Best, Xintong [1] https://lists.apache.org/thread/odftvr5ozyrrl9nl2p3gv4d9fbmt2wvz On Fri, Jul 21, 2023 at 12:43 AM Alexander Fedulov < alexander.fedu...@gmail.com> wrote: > @Leonard > I see your concerns regarding the complexity of migration, but we still > have one year to address them. > > @Xintong > I believe it makes sense to keep it in the list and mark it as a stretch > goal if you have concerns > with the "must have" label. > > Best, > Alexander > > On Thu, 20 Jul 2023 at 11:25, Xintong Song <tonysong...@gmail.com> wrote: > > > Thanks all for the feedback. > > > > I've updated the wiki page as discussed, and started another round of > VOTE > > [1]. > > > > Best, > > > > Xintong > > > > > > [1] https://lists.apache.org/thread/odftvr5ozyrrl9nl2p3gv4d9fbmt2wvz > > > > On Tue, Jul 18, 2023 at 2:26 PM Xintong Song <tonysong...@gmail.com> > > wrote: > > > > > Let me try to summarize the proposed changes on the list. > > > > > > - "Eager State Declaration" should be nice-to-have > > > - "Remove SourceFunction / SinkFunction / SinkV1" should be changed > to > > > "Remove SinkV1", and remain must-to-have > > > - "Remove Queryable State" should be nice-to-have. It will be > > > deprecated in 1.18, but the hard removal requires community > > discussion and > > > vote, which may or may not happen in 2.0. > > > - "Refactor the API modules" should be TBD. > > > - I also noticed Zhenqiu Huang has already changed "Drop > YARN-specific > > > mutating GET REST endpoints" from TBD to must-have, which I'd like > to > > bring > > > up here for attention. > > > > > > I'd leave this discussion open for the next couple of days. If there > are > > > no objections, I'll update the list and start another round of voting. > > > > > > In addition, I'd like to cross-post from the other thread [1] that: > > > > > > I'm not aware of any decision that has already been made by the > community > > >> regarding after which 1.x minor release will we ship the 2.0 major > > release. > > > > > > > > > > > >> I also don't think we should push all the deprecation works in 1.18. > > >> > > > > > > > > >> Deciding to deprecate / remove an API definitely deserves thorough > > >> discussions and FLIP, which takes time, and I don't think we should > > >> compromise that for any reason. > > > > > > > > > > > >> Assuming at some point we want to ship the 2.0 release, and there are > > >> some deprecated APIs that we want to remove but have not fulfilled the > > >> migration period required by FLIP-321, I see 3 options to move > forward. > > > > > > 1. Not removing the deprecated APIs in 2.0, carrying them until 3.0. > > > > > > 2. Postpone the 2.0 release for another minor release. > > > > > > 3. Considering such APIs as exceptions of FLIP-321. > > > > > > > > > > > >> Trying to deprecate things early is still helpful, because it reduces > > the > > >> number of APIs we need to consider when deciding between the options. > > >> However, that must not come at the price of rush decisions. I'd > suggest > > >> developers to design / discuss / vote the breaking changes at their > > pace, > > >> and we evaluate the status and choose between the options later (maybe > > >> around the time releasing 1.19). > > >> > > > > > > Best, > > > > > > Xintong > > > > > > > > > [1] https://lists.apache.org/thread/m0b1v2htd0l7oqo6ypf8lnjyjo817bmm > > > > > > > > > > > > On Mon, Jul 17, 2023 at 6:33 PM Yuan Mei <yuanmei.w...@gmail.com> > wrote: > > > > > >> Hey Yun and Xintong, > > >> > > >> (Had a quick offline discussion with Yun) > > >> 1. I agree the current implementation of the queryable state is not a > > >> blocker of anything related to disaggregated state management. They > are > > >> different things. > > >> 2. On the other hand, "queryable snapshot" is not a completely > > equivalent > > >> substitution of "queryable state". > > >> 3. But in whatever way, I think the way how "queryable state" is > > designed > > >> is not the right way to move forward. > > >> 4. "Deprecating queryable state" is put as a must-have because this > > topic > > >> has been raised many times along the way. It seems to reach an > agreement > > >> every time as mentioned by Xingtong, but no one really takes the > action. > > >> > > >> I am suggesting: > > >> > > >> 1. Remove "Deprecating queryable state" from the must-have list (since > > it > > >> does not meet the requirements of "must-have") > > >> 2. But I am still hoping we can move things forward, so let's put > > >> the @Deprecated annotation on it > > >> 3. Removal of the code follows a formal community discussion and vote. > > >> > > >> Best > > >> Yuan > > >> > > >> > > >> > > >> > > >> On Mon, Jul 17, 2023 at 3:40 PM Xintong Song <tonysong...@gmail.com> > > >> wrote: > > >> > > >> > Thanks for the clarification. > > >> > > > >> > If the list of "Remove deprecated APIs" means, we must remove the > code > > >> in > > >> > > Flink-2.0 initial release, I would vote -1 for queryable state > > before > > >> we > > >> > > get an alternative. > > >> > > > >> > > > >> > FYI, the removal of queryable state is currently marked as the > > >> `must-have` > > >> > priority. Of course it's not a final decision and that's exactly > why > > we > > >> > are collecting feedback about the list now. > > >> > > > >> > Best, > > >> > > > >> > Xintong > > >> > > > >> > > > >> > > > >> > On Mon, Jul 17, 2023 at 3:15 PM Yun Tang <myas...@live.com> wrote: > > >> > > > >> > > Hi Xintong, > > >> > > > > >> > > If the current implementation of queryable state would not block > the > > >> > > implementation of disaggregated state-backends. > > >> > > I prefer to not removing the implementation until we have a better > > >> > > solution (maybe based on the queryable snapshot) cc @Yuan. > > >> > > > > >> > > If the list of "Remove deprecated APIs" means, we must remove the > > >> code in > > >> > > Flink-2.0 initial release, I would vote -1 for queryable state > > before > > >> we > > >> > > get an alternative. > > >> > > And I will raise the concern in the Flink roadmap discussion. > > >> > > > > >> > > > > >> > > Best > > >> > > Yun Tang > > >> > > ________________________________ > > >> > > From: Xintong Song <tonysong...@gmail.com> > > >> > > Sent: Monday, July 17, 2023 10:07 > > >> > > To: dev@flink.apache.org <dev@flink.apache.org> > > >> > > Subject: Re: [VOTE] Release 2.0 must-have work items > > >> > > > > >> > > @Yun, > > >> > > I see your point that the ability queryable states trying to > provide > > >> is > > >> > > meaningful but the current implementation of the feature is > > >> problematic. > > >> > So > > >> > > what's your opinion on deprecating the current queryable state? Do > > you > > >> > > think we need to wait until there is a new implementation of > > queryable > > >> > > state to remove the current one? Or maybe the current > implementation > > >> is > > >> > not > > >> > > well functional anyway and we can treat the removal of it as > > >> > > independent from introducing a new one? > > >> > > > > >> > > However, I don't want to make users feel that this feature cannot > be > > >> done > > >> > > > well, and maybe we can redesign this feature. > > >> > > > > > >> > > TBH, the impression that I got from the roadmap[1] is that the > > >> queryable > > >> > > state is retiring and will be replaced by the state processor api. > > If > > >> > this > > >> > > is not the impression we want users to have, you probably also > need > > to > > >> > > raise it in the roadmap discussion [2]. > > >> > > > > >> > > Best, > > >> > > > > >> > > Xintong > > >> > > > > >> > > > > >> > > [1] https://flink.apache.org/roadmap > > >> > > > > >> > > [2] > > https://lists.apache.org/thread/szdr4ngrfcmo7zko4917393zbqhgw0v5 > > >> > > > > >> > > > > >> > > > > >> > > On Mon, Jul 17, 2023 at 9:53 AM Xintong Song < > tonysong...@gmail.com > > > > > >> > > wrote: > > >> > > > > >> > > > I'd propose to downgrade "Refactor the API modules" to TBD. The > > >> > original > > >> > > > proposal was based on the condition that we are allowed to > > introduce > > >> > > > in-place API breaking changes in release 2.0. As the migration > > >> period > > >> > is > > >> > > > introduced, and we are no longer planning to do in-place > changes / > > >> > > > removal for DataStream (and same for APIs in `flink-core`), we > > need > > >> to > > >> > > > re-evaluate whether it's feasible to do things like moving > classes > > >> to > > >> > > > different module / packages, turning concrete classes into > > >> interfaces > > >> > on > > >> > > > the API classes. > > >> > > > > > >> > > > Best, > > >> > > > > > >> > > > Xintong > > >> > > > > > >> > > > > > >> > > > > > >> > > > On Mon, Jul 17, 2023 at 1:10 AM Yun Tang <myas...@live.com> > > wrote: > > >> > > > > > >> > > >> I agree that we could downgrade "Eager state declaration" to a > > >> > > >> nice-to-have feature. > > >> > > >> > > >> > > >> For the depreciation of "queryable state", can we just rename > to > > >> > > >> deprecate "current implementation of queryable state"? The > > feature > > >> to > > >> > > query > > >> > > >> the internal state is actually very useful for debugging and > > could > > >> > > provide > > >> > > >> more possibility to extend FlinkSQL more like a database. > > >> > > >> > > >> > > >> Just as Yuan replied in the previous email [1], current > > >> implementation > > >> > > of > > >> > > >> queryable state has many problems in design. However, I don't > > want > > >> to > > >> > > make > > >> > > >> users feel that this feature cannot be done well, and maybe we > > can > > >> > > redesign > > >> > > >> this feature. As far as I know, risingwave already support > > >> queryable > > >> > > state > > >> > > >> with better user experience [2]. > > >> > > >> > > >> > > >> > > >> > > >> [1] > > >> https://lists.apache.org/thread/9hmwcjb3q5c24pk3qshjvybfqk62v17m > > >> > > >> [2] https://syntaxbug.com/06a3e7c554/ > > >> > > >> > > >> > > >> Best > > >> > > >> Yun Tang > > >> > > >> ________________________________ > > >> > > >> From: Xintong Song <tonysong...@gmail.com> > > >> > > >> Sent: Friday, July 14, 2023 13:51 > > >> > > >> To: dev@flink.apache.org <dev@flink.apache.org> > > >> > > >> Subject: Re: [VOTE] Release 2.0 must-have work items > > >> > > >> > > >> > > >> Thanks for the support, Yu. > > >> > > >> > > >> > > >> We will have the guideline before removing DataSet. We are > > >> currently > > >> > > >> prioritizing works that need to be done before the 1.18 feature > > >> > freeze, > > >> > > >> and > > >> > > >> will soon get back to working on the guidelines. We expect to > get > > >> the > > >> > > >> guideline ready before or soon after the 1.18 release, which > will > > >> > > >> definitely be before removing DataSet in 2.0. > > >> > > >> > > >> > > >> Best, > > >> > > >> > > >> > > >> Xintong > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> On Fri, Jul 14, 2023 at 1:06 PM Yu Li <car...@gmail.com> > wrote: > > >> > > >> > > >> > > >> > It's great to see the discussion about what we need to > improve > > on > > >> > > >> > (completely) switching from DataSet API to DataStream API > from > > >> the > > >> > > user > > >> > > >> > perspective. I feel that these improvements would happen > faster > > >> > (only) > > >> > > >> when > > >> > > >> > we seriously prepare to remove the DataSet APIs with a target > > >> > release, > > >> > > >> just > > >> > > >> > like what we are doing now. And the same applies to the > SinkV1 > > >> > related > > >> > > >> > discussions (smile). > > >> > > >> > > > >> > > >> > I support Xintong's opinion on keeping "Remove the DataSet > > APIs" > > >> a > > >> > > >> > must-have item, meantime I support Yuxia's opinion that we > > should > > >> > > >> > explicitly let our users know how to migrate their existing > > >> DataSet > > >> > > API > > >> > > >> > based applications afterwards, meaning that the guideline > > Xintong > > >> > > >> mentioned > > >> > > >> > is a must-have (rather than best efforts) before removing the > > >> > DataSet > > >> > > >> APIs. > > >> > > >> > > > >> > > >> > Best Regards, > > >> > > >> > Yu > > >> > > >> > > > >> > > >> > > > >> > > >> > On Wed, 12 Jul 2023 at 14:00, yuxia < > > luoyu...@alumni.sjtu.edu.cn > > >> > > > >> > > >> wrote: > > >> > > >> > > > >> > > >> > > Thanks Xintong for clarification. A guideline to help users > > >> > > migrating > > >> > > >> > from > > >> > > >> > > DataSet to DataStream will definitely be helpful. > > >> > > >> > > > > >> > > >> > > Best regards, > > >> > > >> > > Yuxia > > >> > > >> > > > > >> > > >> > > ----- 原始邮件 ----- > > >> > > >> > > 发件人: "Xintong Song" <tonysong...@gmail.com> > > >> > > >> > > 收件人: "dev" <dev@flink.apache.org> > > >> > > >> > > 发送时间: 星期三, 2023年 7 月 12日 上午 11:40:12 > > >> > > >> > > 主题: Re: [VOTE] Release 2.0 must-have work items > > >> > > >> > > > > >> > > >> > > @Yuxia, > > >> > > >> > > > > >> > > >> > > We are aware of the issue that you mentioned. Actually, I > > don't > > >> > > think > > >> > > >> the > > >> > > >> > > DataStream API can cover everything in the DataSet API in > > >> exactly > > >> > > the > > >> > > >> > same > > >> > > >> > > way, because the fundamental model, concepts and primitives > > of > > >> the > > >> > > two > > >> > > >> > sets > > >> > > >> > > of APIs are completely different. Many of the DataSet APIs, > > >> > > especially > > >> > > >> > > those accessing the full data set at once, do not fit in > the > > >> > > >> DataStream > > >> > > >> > > concepts at all. I think what's important is that users can > > >> > achieve > > >> > > >> the > > >> > > >> > > same function, even if they may need to code in a different > > >> way. > > >> > > >> > > > > >> > > >> > > We have gone through all the existing DataSet APIs, and > > >> > categorized > > >> > > >> them > > >> > > >> > > into 3 kinds: > > >> > > >> > > - APIs that are well supported by DataStream API as is. > E.g., > > >> map, > > >> > > >> reduce > > >> > > >> > > on grouped dataset, etc. > > >> > > >> > > - APIs that can be achieved by DataStream API as is, but > > with a > > >> > > price > > >> > > >> > > (programming complexity, or computation efficiency). E.g., > > >> reduce > > >> > on > > >> > > >> full > > >> > > >> > > dataset, sort partition, etc. Admittedly, there is room for > > >> > > >> improvement > > >> > > >> > on > > >> > > >> > > these. We may keep improving these for the DataStream API, > or > > >> we > > >> > can > > >> > > >> > > concentrate on supporting them better in the new > > >> ProcessFunction > > >> > > API. > > >> > > >> > > Either way, I don't think we should block the retiring of > > >> DataSet > > >> > > API > > >> > > >> on > > >> > > >> > > them. > > >> > > >> > > - There are also a few APIs that cannot be supported by the > > >> > > DataStream > > >> > > >> > API > > >> > > >> > > as is, unless users write their custom operators from the > > >> ground > > >> > up. > > >> > > >> Only > > >> > > >> > > left/rightOuterJoin and combineGroup fall into this > > category. I > > >> > > think > > >> > > >> > > combinedGroup is probably not a problem, because this is > more > > >> > like a > > >> > > >> > > variant of reduceGroup that allows the framework to execute > > >> more > > >> > > >> > > efficiently. As for the outer joins, depending on how badly > > >> this > > >> > is > > >> > > >> > needed, > > >> > > >> > > it can be supported by emitting the non-joined entries upon > > >> > > >> triggering a > > >> > > >> > > window join. > > >> > > >> > > > > >> > > >> > > We are also planning to draft a guideline to help users > > >> migrating > > >> > > from > > >> > > >> > > DataSet to DataStream, which should demonstrate how users > can > > >> > > achieve > > >> > > >> > > things like sort-partition with DataStream API. > > >> > > >> > > > > >> > > >> > > Last but not least, I'd like to point out that the decision > > to > > >> > > >> deprecate > > >> > > >> > > and eventually remove the DataSet API was approved in > > FLIP-131, > > >> > and > > >> > > >> all > > >> > > >> > the > > >> > > >> > > prerequisites mentioned in the FLIP have been completed. > > >> > > >> > > > > >> > > >> > > Best, > > >> > > >> > > > > >> > > >> > > Xintong > > >> > > >> > > > > >> > > >> > > > > >> > > >> > > [1] > > >> > > >> > > > > >> > > >> > > > >> > > >> > > >> > > > > >> > > > >> > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158866741 > > >> > > >> > > > > >> > > >> > > > > >> > > >> > > > > >> > > >> > > On Wed, Jul 12, 2023 at 10:20 AM Jingsong Li < > > >> > > jingsongl...@gmail.com> > > >> > > >> > > wrote: > > >> > > >> > > > > >> > > >> > > > +1 to Leonard and Galen and Jing. > > >> > > >> > > > > > >> > > >> > > > About Source and Sink. > > >> > > >> > > > We're still missing quite a bit of work, including > > >> > functionality, > > >> > > >> > > > including ease of use, including bug fixes, and I'm not > > sure > > >> > we'll > > >> > > >> be > > >> > > >> > > > completely done by 2.0. > > >> > > >> > > > Until that's done, we won't be in a position to clean up > > the > > >> old > > >> > > >> APIs. > > >> > > >> > > > > > >> > > >> > > > Best, > > >> > > >> > > > Jingsong > > >> > > >> > > > > > >> > > >> > > > On Wed, Jul 12, 2023 at 9:41 AM yuxia < > > >> > > luoyu...@alumni.sjtu.edu.cn> > > >> > > >> > > wrote: > > >> > > >> > > > > > > >> > > >> > > > > Hi，Xintong. > > >> > > >> > > > > Sorry to disturb the voting. I just found an email[1] > > about > > >> > > >> DataSet > > >> > > >> > API > > >> > > >> > > > from flink-user-zh channel. And I think it's not just a > > >> single > > >> > > case > > >> > > >> > > > according to my observation. > > >> > > >> > > > > > > >> > > >> > > > > Remove DataSet is a must have item in release-2.0. But > as > > >> the > > >> > > user > > >> > > >> > > email > > >> > > >> > > > said, if we remove DataSet, how users can implement > > >> > > >> Sort/PartitionBy, > > >> > > >> > etc > > >> > > >> > > > as they did with DataSet? > > >> > > >> > > > > Do we will also provide similar api in datastream or > some > > >> > other > > >> > > >> thing > > >> > > >> > > > before we remove DataSet? > > >> > > >> > > > > Btw, as far as I see, with regarding to replcaing > DataSet > > >> with > > >> > > >> > > > Datastream, Datastream are missing many API. I think it > may > > >> well > > >> > > >> take > > >> > > >> > > much > > >> > > >> > > > effort to fully cover the missing api. > > >> > > >> > > > > > > >> > > >> > > > > [1] > > >> > > >> > https://lists.apache.org/thread/syjmt8f74gh8ok3z4lhgt95zl4dzn168 > > >> > > >> > > > > > > >> > > >> > > > > Best regards, > > >> > > >> > > > > Yuxia > > >> > > >> > > > > > > >> > > >> > > > > ----- 原始邮件 ----- > > >> > > >> > > > > 发件人: "Jing Ge" <j...@ververica.com.INVALID> > > >> > > >> > > > > 收件人: "dev" <dev@flink.apache.org> > > >> > > >> > > > > 发送时间: 星期三, 2023年 7 月 12日 上午 1:23:40 > > >> > > >> > > > > 主题: Re: [VOTE] Release 2.0 must-have work items > > >> > > >> > > > > > > >> > > >> > > > > agree with what Leonard said. There are actually more > > >> issues > > >> > wrt > > >> > > >> the > > >> > > >> > > new > > >> > > >> > > > > Source and SinkV2[1] > > >> > > >> > > > > > > >> > > >> > > > > Speaking of must-have vs nice-to-have, I think it > depends > > >> on > > >> > the > > >> > > >> > > > priority. > > >> > > >> > > > > If removing them has higher priority, we should keep > > >> related > > >> > > >> tasks as > > >> > > >> > > > > must-have and make sure enough effort will be put to > > solve > > >> > those > > >> > > >> > issues > > >> > > >> > > > and > > >> > > >> > > > > therefore be able to remove those APIs. > > >> > > >> > > > > > > >> > > >> > > > > Best regards, > > >> > > >> > > > > Jing > > >> > > >> > > > > > > >> > > >> > > > > [1] > > >> > > >> > https://lists.apache.org/thread/90qc9nrlzf0vbvg92klzp9ftxxc43nbk > > >> > > >> > > > > > > >> > > >> > > > > On Tue, Jul 11, 2023 at 10:26 AM Leonard Xu < > > >> > xbjt...@gmail.com> > > >> > > >> > wrote: > > >> > > >> > > > > > > >> > > >> > > > > > Thanks Xintong for driving this great work! But I’ve > to > > >> give > > >> > > my > > >> > > >> > > > > > -1(binding) here： > > >> > > >> > > > > > > > >> > > >> > > > > > -1 to mark "deprecat > > SourceFunction/SinkFunction/Sinkv1" > > >> > item > > >> > > as > > >> > > >> > must > > >> > > >> > > > to > > >> > > >> > > > > > have for release 2.0. > > >> > > >> > > > > > > > >> > > >> > > > > > I do a lot of connector work in the community, and I > > have > > >> > two > > >> > > >> > > insights > > >> > > >> > > > > > from past experience: > > >> > > >> > > > > > > > >> > > >> > > > > > 1. Many developers reported that it is very difficult > > to > > >> > > migrate > > >> > > >> > from > > >> > > >> > > > > > SourceFunction to new Source [1]. The migration of > > >> existing > > >> > > >> > > conenctors > > >> > > >> > > > > > after deprecated SourceFunction is very difficult. > Some > > >> > > >> developers > > >> > > >> > > > (Flavio > > >> > > >> > > > > > Pompermaier) reported that they gave up the migration > > >> > because > > >> > > it > > >> > > >> > was > > >> > > >> > > > too > > >> > > >> > > > > > complicated. I believe it's not a few cases. This > means > > >> that > > >> > > >> > > > deprecating > > >> > > >> > > > > > SourceFunction related interfaces require community > > >> > > >> contributors to > > >> > > >> > > > reduce > > >> > > >> > > > > > the migration cost before starting the migration > work. > > >> > > >> > > > > > > > >> > > >> > > > > > 2. IIRC, the function of SinkV2 cannot currently > cover > > >> > > >> SinkFunction > > >> > > >> > > as > > >> > > >> > > > > > described in FLIP-287[2], it means the migration path > > >> after > > >> > > >> > deprecate > > >> > > >> > > > > > SinkFunction/Sinkv1 does not exist, thus we cannot > mark > > >> the > > >> > > >> related > > >> > > >> > > > > > interfaces of sinkfunction/sinkv1 as deprecated in > > 1.18. > > >> > > >> > > > > > > > >> > > >> > > > > > Based on these two cognitions, I think we should not > > mark > > >> > > these > > >> > > >> > > > interfaces > > >> > > >> > > > > > as must to have in 2.0. Maintaining the two sets of > > >> > > source/sink > > >> > > >> > > > interfaces > > >> > > >> > > > > > is not a concern for me, users can choose the > interface > > >> to > > >> > > >> > implement > > >> > > >> > > > > > according to their energy and needs. > > >> > > >> > > > > > > > >> > > >> > > > > > Btw, some work items in 2.0 are marked as must to > have, > > >> but > > >> > no > > >> > > >> > > > contributor > > >> > > >> > > > > > has claimed them yet. I think this is a risk and hope > > the > > >> > > >> Release > > >> > > >> > > > Managers > > >> > > >> > > > > > could pay attention to it. > > >> > > >> > > > > > > > >> > > >> > > > > > Thank you all RMs for your work, sorry again for > > >> > interrupting > > >> > > >> the > > >> > > >> > > vote > > >> > > >> > > > > > > > >> > > >> > > > > > Best, > > >> > > >> > > > > > Leonard > > >> > > >> > > > > > > > >> > > >> > > > > > [1] > > >> > > >> > > > https://lists.apache.org/thread/sqq26s9rorynr4vx4nhxz3fmmxpgtdqp > > >> > > >> > > > > > [2] > > >> > > >> > > > > > > > >> > > >> > > > > > >> > > >> > > > > >> > > >> > > > >> > > >> > > >> > > > > >> > > > >> > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=240880853 > > >> > > >> > > > > > > > >> > > >> > > > > > > On Jul 11, 2023, at 4:11 PM, Yuan Mei < > > >> > > yuanmei.w...@gmail.com > > >> > > >> > > > >> > > >> > > > wrote: > > >> > > >> > > > > > > > > >> > > >> > > > > > > As a second thought, I think "Eager State > > Declaration" > > >> is > > >> > > >> > probably > > >> > > >> > > > not a > > >> > > >> > > > > > > must-have. > > >> > > >> > > > > > > > > >> > > >> > > > > > > I was originally thinking it is a prerequisite for > > >> "state > > >> > > >> > querying > > >> > > >> > > > for > > >> > > >> > > > > > > disaggregated state management". > > >> > > >> > > > > > > > > >> > > >> > > > > > > Since disaggregated state management itself is not > a > > >> > > >> must-have, > > >> > > >> > > > "Eager > > >> > > >> > > > > > > State Declaration" is not as well. We can downgrade > > it > > >> to > > >> > > >> "nice > > >> > > >> > to > > >> > > >> > > > have" > > >> > > >> > > > > > if > > >> > > >> > > > > > > no objection. > > >> > > >> > > > > > > > > >> > > >> > > > > > > Best > > >> > > >> > > > > > > > > >> > > >> > > > > > > Yuan > > >> > > >> > > > > > > > > >> > > >> > > > > > > On Mon, Jul 10, 2023 at 7:02 PM Jing Ge > > >> > > >> > <j...@ververica.com.invalid > > >> > > >> > > > > > >> > > >> > > > > > wrote: > > >> > > >> > > > > > > > > >> > > >> > > > > > >> +1 > > >> > > >> > > > > > >> > > >> > > >> > > > > > >> On Mon, Jul 10, 2023 at 12:52 PM Yu Li < > > >> car...@gmail.com > > >> > > > > >> > > >> > wrote: > > >> > > >> > > > > > >> > > >> > > >> > > > > > >>> +1 (binding) > > >> > > >> > > > > > >>> > > >> > > >> > > > > > >>> Thanks for driving this and great to see us > moving > > >> > > forward. > > >> > > >> > > > > > >>> > > >> > > >> > > > > > >>> Best Regards, > > >> > > >> > > > > > >>> Yu > > >> > > >> > > > > > >>> > > >> > > >> > > > > > >>> > > >> > > >> > > > > > >>> On Mon, 10 Jul 2023 at 11:59, Feng Wang < > > >> > > >> wangfeng...@gmail.com > > >> > > >> > > > > >> > > >> > > > wrote: > > >> > > >> > > > > > >>> > > >> > > >> > > > > > >>>> +1 > > >> > > >> > > > > > >>>> Thanks for driving this, looking forward to the > > next > > >> > > stage > > >> > > >> of > > >> > > >> > > > flink. > > >> > > >> > > > > > >>>> > > >> > > >> > > > > > >>>> On Fri, Jul 7, 2023 at 5:31 PM Xintong Song < > > >> > > >> > > > tonysong...@gmail.com> > > >> > > >> > > > > > >>> wrote: > > >> > > >> > > > > > >>>> > > >> > > >> > > > > > >>>>> Hi all, > > >> > > >> > > > > > >>>>> > > >> > > >> > > > > > >>>>> I'd like to start the VOTE for the must-have > work > > >> > items > > >> > > >> for > > >> > > >> > > > release > > >> > > >> > > > > > >> 2.0 > > >> > > >> > > > > > >>>>> [1]. The corresponding discussion thread is > [2]. > > >> > > >> > > > > > >>>>> > > >> > > >> > > > > > >>>>> Please note that once the vote is approved, any > > >> > changes > > >> > > to > > >> > > >> > the > > >> > > >> > > > > > >>> must-have > > >> > > >> > > > > > >>>>> items (adding / removing must-have items, > > changing > > >> the > > >> > > >> > > priority) > > >> > > >> > > > > > >>> requires > > >> > > >> > > > > > >>>>> another vote. Assigning contributors / > reviewers, > > >> > > updating > > >> > > >> > > > > > >>> descriptions / > > >> > > >> > > > > > >>>>> progress, changes to nice-to-have items do not > > >> require > > >> > > >> > another > > >> > > >> > > > vote. > > >> > > >> > > > > > >>>>> > > >> > > >> > > > > > >>>>> The vote will be open until at least July 12, > > >> > following > > >> > > >> the > > >> > > >> > > > consensus > > >> > > >> > > > > > >>>>> voting process. Votes of PMC members are > binding. > > >> > > >> > > > > > >>>>> > > >> > > >> > > > > > >>>>> Best, > > >> > > >> > > > > > >>>>> > > >> > > >> > > > > > >>>>> Xintong > > >> > > >> > > > > > >>>>> > > >> > > >> > > > > > >>>>> > > >> > > >> > > > > > >>>>> [1] > > >> > > >> > > > > > >> https://cwiki.apache.org/confluence/display/FLINK/2.0+Release > > >> > > >> > > > > > >>>>> > > >> > > >> > > > > > >>>>> [2] > > >> > > >> > > > > > >> > https://lists.apache.org/thread/l3dkdypyrovd3txzodn07lgdwtwvhgk4 > > >> > > >> > > > > > >>>>> > > >> > > >> > > > > > >>>> > > >> > > >> > > > > > >>> > > >> > > >> > > > > > >> > > >> > > >> > > > > > > > >> > > >> > > > > > > > >> > > >> > > > > > >> > > >> > > > > >> > > >> > > > >> > > >> > > >> > > > > > >> > > > > >> > > > >> > > > > > >
