Thanks for the inputs, Matthias, - FLINK-4503: Yes, this should be subsumed by "Deprecated methods/fields/classes in DataStream", which doesn't really need any action in 1.18. Sorry for overlooking it.
- FLINK-5875: Based on the JIRA descriptions, it seems this only makes sense if we want to accept arrays as keys in DataStream. I'm not entirely sure about the necessity and feasibility of the latter. To be specific, I'm not aware of anyone complaining about not being able to use arrays as keys, and I don't know whether there will be other negative effects by allowing arrays as keys. That's why I think more investigations are needed for this, thus putting it as TBD. - FLINK-15470: I think you're right. The YARN properties file is not a public API, but it is mentioned in documentation [1], and the removal of it would lead to behavior changes (having to always specify the deployment target). It would be nice to update the documentation and log warning messages in advance. Best, Xintong [1] https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/resource-providers/yarn/#session-mode On Thu, Jul 20, 2023 at 8:05 PM Matthias Pohl <matthias.p...@aiven.io.invalid> wrote: > Sorry for the late reply in that matter. I was off the last few days. I > should have made this clear in the ML. Anyway, I went over the issues as > well. Xintong's summary matches more or less my findings aside from the > following items: > > - FLINK-4503 (remove deprecated methods from CoGroupedStreams and > JoinedStreams) was not mentioned in the above summary (AFAICS) but is > most-likely subsumed by the deprecated DataStream API cleanup > - FLINK-5875 (using TypeComparator.hash() instead of Object.hashCode()) > felt to me like a nice-to-have item because it fixes a bug that was treated > with a restrictive workaround. But I see your point that it should have > been raised in the ML if it would have been a bigger issue. > - FLINK-15470 (remove YARN properties file): Shouldn't we add a log warning > and update the documentation as part of 1.18 to make this issue happen? In > this sense, I'd say that we should list FLINK-15470 under 1.18 changes > necessary > > Best, > Matthias > > > On Wed, Jul 19, 2023 at 10:27 AM Martijn Visser <martijnvis...@apache.org> > wrote: > > > First off, good discussion on these topics. > > > > +1 on Xintong's latest proposal in this thread > > > > On Wed, Jul 19, 2023 at 5:16 AM Xintong Song <tonysong...@gmail.com> > > wrote: > > > >> I went through the remaining Jira tickets with 2.0.0 fix-version and are > >> not included in FLINK-3975. > >> > >> I skipped the 3 umbrella tickets below and their subtasks, which are > newly > >> created for the 2.0 work items. > >> > >> - FLINK-32377 Breaking REST API changes > >> - FLINK-32378 Breaking Metrics system changes > >> - FLINK-32383 2.0 Breaking configuration changes > >> > >> I'd suggest going ahead with the following tickets. > >> > >> - Need action in 1.18 > >> - FLINK-29739: Already listed in the release 2.0 wiki. Needs mark > >> all > >> Scala APIs as deprecated. > >> - Need no action in 1.18 > >> - FLINK-23620: Already listed in the release 2.0 > >> - FLINK-15470/30246/32437: Behavior changes, no API to be > deprecated > >> > >> I'd suggest not doing the following tickets. > >> > >> - FLINK-11409: Subsumed by "Convert user-facing concrete classes into > >> interfaces" in the release 2.0 wiki > >> > >> I'd suggest leaving the following tickets as TBD, and would be slightly > in > >> favor of not doing them unless someone volunteers to look more into > them. > >> > >> - FLINK-10113 Drop support for pre 1.6 shared buffer state > >> - FLINK-10374 [Map State] Let user value serializer handle null > values > >> - FLINK-13928 Make windows api more extendable > >> - FLINK-17539 Migrate the configuration options which do not follow > the > >> xyz.max/min pattern > >> > >> > >> Best, > >> > >> Xintong > >> > >> > >> > >> On Tue, Jul 18, 2023 at 5:20 PM Wencong Liu <liuwencle...@163.com> > wrote: > >> > >> > Hi Chesnay, > >> > Thanks for the reply. I think it is reasonable to remove the > >> configuration > >> > argument > >> > in AbstractUdfStreamOperator#open if it is consistently empty. I'll > >> > propose a discuss > >> > about the specific actions in FLINK-6912 at a later time. > >> > > >> > > >> > Best, > >> > Wencong Liu > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > At 2023-07-18 16:38:59, "Chesnay Schepler" <ches...@apache.org> > wrote: > >> > >On 18/07/2023 10:33, Wencong Liu wrote: > >> > >> For FLINK-6912: > >> > >> > >> > >> There are three implementations of RichFunction that actually > >> use > >> > >> the Configuration parameter in RichFunction#open: > >> > >> 1. ContinuousFileMonitoringFunction#open: It uses the > >> configuration > >> > >> to configure the FileInputFormat. [1] > >> > >> 2. OutputFormatSinkFunction#open: It uses the configuration > >> > >> to configure the OutputFormat. [2] > >> > >> 3. InputFormatSourceFunction#open: It uses the configuration > >> > >> to configure the InputFormat. [3] > >> > > > >> > >And none of them should have any effect since the configuration is > >> empty. > >> > > > >> > >See > >> > > org.apache.flink.streaming.api.operators.AbstractUdfStreamOperator#open. > >> > > >> > > >
