Regarding SinkV1 vs. SinkV2: Is StreamingFileSink a SinkV1-related interface that is proposed to be removed? In a separate thread, it was discussed how it's important not to remove StreamingFileSink as long as this critical issue with SinkV2 is still outstanding -- https://issues.apache.org/jira/plugins/servlet/mobile#issue/FLINK-30238 -- because of the prospect of data loss when stopping and restarting jobs with savepoints.
Thanks, Galen On Tue, Jul 11, 2023 at 7:47 AM Leonard Xu <xbjt...@gmail.com> wrote: > Hi, Xintong > > > Could you please clarify what exact changes you are proposing to make on > > the existing list? > > - Are you suggesting removing the item "Remove deprecated APIs - > > SourceFunction / SinkFunction / SinkV1", or are you suggesting > downgrading > > it as nice-to-have? > > I prefer to remove the item as we cannot deprecate SourceFunction / > SinkFunction related interfaces in 1.18, thus he 2.0 version would not > satisfy two minor versions condition and would not remove them as well. > > > - You said SinkV2 cannot cover SinkFunction. Then how about SinkV1? Is it > > covered by SinkV2? Should it be removed or preserved? > > SinkV2 related interfaces covers SinkV1 related interfaces well, and > SinkV1 related interfaces have been deprecated, I think they can be removed > in 2.0 safely. > > In a word, my proposal is replace must have item "Remove deprecated APIs - > SourceFunction / SinkFunction / SinkV1" with must have item "Remove > deprecated APIs SinkV1" . > > Best, > Leonard > > > > > > > > > > > Best, > > > > Xintong > > > > > > > > On Tue, Jul 11, 2023 at 4:26 PM 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 > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > >> > >
