ProgressMonitoringIncidentListener
to handle all such incidents and perform corresponding analysis (maybe the
ExecutionGraph is needed in the context).
2. Users may provide custom logic to analyze the progress.
Thanks,
Jiangjie (Becket) Qin
On Wed, Jul 3, 2019 at 4:53 PM Hwanju Kim wrote:
> Hi,
>
> I am sh
at do people think. If there is no further
objection, I'd suggest to conclude this discussion in 72 hours and move to
a lazy majority voting. (For decisions like this, maybe only votes from
PMCs should be considered as binding?)
Thanks,
Jiangjie (Becket) Qin
On Fri, Jun 28, 2019 at 10:33 AM Co
Hi Aljoscha,
Thanks for the quick response. Yes, you are right. I meant "Voted and
accepted FLIPs should be immutable". Sorry for the confusion.
Thanks,
Jiangjie (Becket) Qin
On Tue, Jul 9, 2019 at 10:09 PM Aljoscha Krettek
wrote:
> +1 to what Becket said.
>
> I have o
e two jobs will always be different
after that, right?
Thanks,
Jiangjie (Becket) Qin
On Mon, Jul 8, 2019 at 9:53 PM Kostas Kloudas wrote:
> Hi Devs,
>
> Currently there is a number of efforts around checkpoints/savepoints, as
> reflected by the number of FLIPs. From a quick look FLIP-
ask for a FLIP if
needed.
Thanks,
Jiangjie (Becket) Qin
On Wed, Jul 10, 2019 at 11:55 PM Robert Metzger wrote:
> Thanks for your summary Becket.
>
> Your list of items makes sense to me.
> I wonder if we should start working on some project Bylaws to write down
> how we want t
drafted a Flink bylaws page and would like to start a discussion
thread on this.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
The bylaws will affect everyone in the community. It'll be great to hear
your thoughts.
Thanks,
Jiangjie (Becket) Qin
[1]
http://a
cal
to Kafka. But Robert has already caught a few inconsistent places. So it
might still worth going through it to make sure we truly agree on them.
Otherwise we may end up modifying them shortly after adoption.
Thanks again folks, for all the valuable feedback. These are great
discussion.
Jia
Congrats, Rong!
On Fri, Jul 12, 2019 at 1:13 AM Xingcan Cui wrote:
> Congrats Rong!
>
> Best,
> Xingcan
>
> On Jul 11, 2019, at 1:08 PM, Shuyi Chen wrote:
>
> Congratulations, Rong!
>
> On Thu, Jul 11, 2019 at 8:26 AM Yu Li wrote:
>
>> Congratulations Rong!
>>
>> Best Regards,
>> Yu
>>
>>
>> O
nd or not.
>
The vote requires a minimum length of 3 days, but it could last longer in
order to collect enough binding votes. In most cases, only the committers
with enough expertise / interest would vote on the FLIP.
Thanks,
Jiangjie (Becket) Qin
On Fri, Jul 12, 2019 at 5:07 PM Piotr Nowojski
8日 +0800 PM6:29，Haibo Sun >，写道：
> > > > > > > > >> Congratulations Becket!Best,
> > > > > > > > >> Haibo
> > > > > > > > >> 在 2019-07-18 17:51:06，"Hequn Cheng" >
> > > 写道：
> > > > > > > > >>> Congrat
making
such decisions.
Re: Robert,
I agree we can simply remove the requirement of +1 from a non-author
committer and revisit it in a bit. After all, it does not make sense to
have a bylaw that we cannot afford. I have just updated the bylaws wiki.
Thanks,
Jiangjie (Becket) Qin
On Fri, Jul 19
s?
Thanks Robert and Daryl for the great effort. Looking forward to seeing
this get published soon!!
I agree with Marta that
Jiangjie (Becket) Qin
On Sat, Jul 20, 2019 at 1:34 AM Marta Paes Moreira
wrote:
> Hey, Robert.
>
> I will keep an eye on the overall progress and get started on
[Sorry for the incomplete message. Clicked send by mistake...]
I agree with Marta that it might be good to have multi-language support as
a mid-term goal.
Jiangjie (Becket) Qin
On Sat, Jul 20, 2019 at 11:22 AM Becket Qin wrote:
> The website is awesome! I really like its conciseness and
for at least 3 times and at least 7 days between each time.
If a binding voter still did not respond, the vote from that voter will be
excluded from the 2/3 majority counting.
This would ensure the coverage at our best effort while still let the 2/3
majority vote make progress.
Th
+1. Sounds a good idea to me.
On Sat, Jul 20, 2019 at 7:07 PM Dian Fu wrote:
> Thanks Jark for the proposal, sounds reasonable for me. +1. This ML could
> be used for all the build notifications including master and CRON jobs.
>
> > 在 2019年7月20日，下午2:55，Xu Forward 写道：
> >
> > +1 ,Thanks jark for
more on the technical side.
Thanks,
Jiangjie (Becket) Qin
On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske wrote:
> Hi all,
>
> First of all thank you very much Becket for starting this discussion!
> I think it is a very good idea and overdue to formally define some of our
> community
Congrats, Zhijiang!
On Tue, Jul 23, 2019 at 2:01 PM Jark Wu wrote:
> Congratulations Zhijiang!
>
>
> On Tue, 23 Jul 2019 at 11:30, vino yang wrote:
>
> > Congratulations Zhijiang!
> >
> > Haibo Sun 于2019年7月23日周二 上午10:48写道：
> >
> > > Congrats, Zhejiang!
> > >
> > >
> > > Best,
> > > Haibo
> > >
Congrats, Kurt. Well deserved!
Jiangjie (Becket) Qin
On Wed, Jul 24, 2019 at 1:11 AM Xuefu Z wrote:
> Congratulations, Kurt!
>
> On Tue, Jul 23, 2019 at 7:48 AM Fabian Hueske wrote:
>
> > Congrats Kurt!
> >
> > Cheers, Fabian
> >
> > Am Di., 23
priv...@flink.apache.org.
3. Adde the term to ensure 2/3 majority voting is still doable when there
are non-emeritus committers / PMCs who do not cast the vote.
Please let me know if you have any further thoughts.
Thanks,
Jiangjie (Becket) Qin
On Tue, Jul 23, 2019 at 10:18 AM Becket Qin wrote
Hi Everyone,
Thanks for all the discussion and feedback.
It seems that we have almost reached consensus. I'll leave the discussion
thread open until this Friday. If there is no more concerns raised, I'll
start a voting thread after that.
Thanks,
Jiangjie (Becket) Qin
On Fri, Jul 26,
there any producer sending "old" messages to the Kafka cluster which may
cause those messages to be dropped by Flink due to their old timestamp?
Unfortunately the image does not work in apache mailing list. Can you post
the image somewhere and send the link instead?
Thanks,
Jiangjie (B
+1 as well. If this affects the fault tolerance of streaming iteration, I'd
consider this as a bug fix.
On Thu, Aug 1, 2019 at 11:44 AM Till Rohrmann wrote:
> I've quickly glanced over the changes and I would be ok with backporting it
> if it helps fixing fault tolerance of streaming iterations.
Congrats, Hequn! Well deserved!
On Wed, Aug 7, 2019 at 11:16 AM Zili Chen wrote:
> Congrats Hequn!
>
> Best,
> tison.
>
>
> Jeff Zhang 于2019年8月7日周三 下午5:14写道：
>
>> Congrats Hequn!
>>
>> Paul Lam 于2019年8月7日周三 下午5:08写道：
>>
>>> Congrats Hequn! Well deserved!
>>>
>>> Best,
>>> Paul Lam
>>>
>>> 在 20
. Clarified what is considered as the adoption of new codebase.
I think we almost reached consensus. I'll start a voting thread in two days
if there is no new concerns.
Thanks,
Jiangjie (Becket) Qin
On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen wrote:
> I added a clarification to the table, cl
:
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Flink-project-bylaws-td30409.html
The vote will be open for at least 6 days. PMC members' votes are
considered as binding. The vote requires 2/3 majority of the binding +1s to
pass.
Thanks,
Jiangjie (Becket) Qin
Hi folks,
Thanks for all the discussion and support. I have started the voting thread.
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html
Thanks,
Jiangjie (Becket) Qin
On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske wrote:
> Thanks for
the removal. In some sense, it is more
difficult than with 2/3 majority to remove a committer / PMC member. Also,
it might be a hard decision for some PMC members if they have never worked
with the person in question. That said, I am OK to change it to 2/3
majority as this will happen very rarely.
Tha
+1 as well. starting the work in parallel may also give some insights on
whether some additional API on SourceReader is needed in order to support
the interaction between SourceReader and runtime.
On Mon, Aug 12, 2019 at 11:29 AM Stephan Ewen wrote:
> +1 to looking at the Source Reader interface
Hi Robert,
That's a good suggestion. Will you help to change the permission on that
page?
Thanks,
Jiangjie (Becket) Qin
On Mon, Aug 12, 2019 at 2:41 PM Robert Metzger wrote:
> Thanks for starting the vote.
> How about putting a specific version in the wiki up for voting, or
&g
of
making this as a blocker for 1.9. Want to check what do others think.
Thanks,
Jiangjie (Becket) Qin
On Mon, Aug 12, 2019 at 2:04 PM Zili Chen wrote:
> Hi Kurt,
>
> Thanks for your explanation. For [1] I think at least we should change
> the JIRA issue field, like unset the f
Hi Till,
Yes, I think we have already documented in that way. So technically
speaking it is fine to change it later. It is just better if we could avoid
doing that.
Thanks,
Jiangjie (Becket) Qin
On Mon, Aug 12, 2019 at 4:09 PM Till Rohrmann wrote:
> Could we say that the PubSub connector
That sounds good to me. I was initially trying to piggyback it into an RC,
but fell behind and was not able to catch the last one.
Thanks,
Jiangjie (Becket) Qin
On Mon, Aug 12, 2019 at 4:25 PM Till Rohrmann wrote:
> I agree that it would be nicer. Not sure whether we should cancel the
en
>> addressed until very recently. Maybe we could include it on the shortlist
>> of nice-to-do things which we do in case that the RC gets cancelled.
>>
>> Cheers,
>> Till
>>
>> On Mon, Aug 12, 2019 at 4:18 PM Becket Qin wrote:
>>
>>> Hi Till,
>
bout this addition.
Thanks,
Jiangjie (Becket) Qin
On Mon, Aug 12, 2019 at 11:19 AM Becket Qin wrote:
> Hi Maximillian,
>
> Thanks for the feedback. Please see the reply below:
>
> Step 2 should include a personal email to the PMC members in question.
>
> I'm afraid
Hi Robert,
Thanks for help apply the changes. I agree we should freeze the change to
the bylaws page starting from now. For this particular addition of
clarification, I'll send a notice in the voting thread to let who have
already voted to know.
Thanks,
Jiangjie (Becket) Qin
On Tue, A
ddition does not really change anything the bylaws meant to set. It
is simply a clarification. If anyone who have casted the vote objects,
please feel free to withdraw the vote.
Thanks,
Jiangjie (Becket) Qin
On Tue, Aug 13, 2019 at 1:29 PM Piotr Nowojski wrote:
> +1
>
> > On 13
Congratulations, Andrey!
On Wed, Aug 14, 2019 at 4:35 PM Thomas Weise wrote:
> Congrats!
>
>
> On Wed, Aug 14, 2019, 7:12 AM Robert Metzger wrote:
>
> > Congratulations! Very happy to have you onboard :)
> >
> > On Wed, Aug 14, 2019 at 4:06 PM Kostas Kloudas
> wrote:
> >
> > > Congratulations
Hi Chesnay,
Thanks for responding. I think cc private@ is a good idea. I just added
that to the CC list.
We are following the 2/3 majority voting scheme defined in the bylaws here.
I should have referred to the terms in the bylaws instead rephrasing them.
Thanks,
Jiangjie (Becket) Qin
On
include that into RC3 as well?
Thanks,
Jiangjie (Becket) Qin
On Mon, Aug 19, 2019 at 9:43 AM Tzu-Li (Gordon) Tai
wrote:
> Hi,
>
> https://issues.apache.org/jira/browse/FLINK-13752 turns out to be an
> actual
> blocker, so we would have to close this RC now in favor of a new one.
&
Thanks for sharing your thoughts, Thomas, Henry and Stephan. I also think
the committers are supposed to be mature enough to know when a review on
their own patch is needed.
@Henry, just want to confirm, are you +1 on the proposed bylaws?
Thanks,
Jiangjie (Becket) Qin
On Tue, Aug 20, 2019 at
I agree with Stephan. It will be good to see if we can align those two
efforts so that we don't write code that are soon to be refactored again.
Thanks,
Jiangjie (Becket) Qin
On Tue, Aug 20, 2019 at 10:50 AM Stephan Ewen wrote:
> Just FYI - Becket, Aljoscha, and me are working on fles
is still not determined by
then.
Also CCing private@ in case one did not setup the Apache email forwarding.
Thanks,
Jiangjie (Becket) Qin
On Thu, Aug 22, 2019 at 8:03 AM Henry Saputra
wrote:
> Oh yeah, +1 LGTM
>
> Thanks for working on this.
>
> - Henry
>
> On Tue, Au
Thanks for collecting the ideas of Bylaws changes. It is a good idea!
Jiangjie (Becket) Qin
On Thu, Aug 22, 2019 at 12:11 PM Robert Metzger wrote:
> I have started a Wiki page (editable by all) for collecting ideas for
> Bylaws changes, so that we can batch changes together and then v
+1, makes sense. BTW, we probably need a FLIP as this is a public API
change.
On Sat, Aug 24, 2019 at 8:11 AM SHI Xiaogang wrote:
> +1 to replace Flink's time with Java's Duration.
>
> Besides, i also suggest to use Java's Instant for "point-in-time".
> It can take care of time units when we cal
, Dawid, Xintong, Yu, Jingsong,
Yun, Jark, Biao, Becket)
There are 23 PMC members of Flink and we have received 16 binding +1s. The
binding +1s have reached 2/3 majority.
*The Flink bylaws proposal has passed!*
Thanks everyone for the discussion and voting!
Jiangjie (Becket) Qin
On Tue, Aug 27
Google
doc before voting? The FLIP wiki allows track the modification history and
has a more established structure to ensure nothing is missed.
Thanks,
Jiangjie (Becket) Qin
On Tue, Aug 27, 2019 at 11:34 PM Timo Walther wrote:
> Hi everyone,
>
> I updated the FLIP proposal one mor
about we name it something like
extractConfiguration()? I am just trying to see if we can make it clear
this is not something like fromBytes() and toBytes().
Thanks,
Jiangjie (Becket) Qin
On Thu, Aug 29, 2019 at 6:09 PM Timo Walther wrote:
> Hi Becket,
>
> let me try to clarify some o
that clear. Maybe a clear Java
doc is sufficient.
Thanks,
Jiangjie (Becket) Qin
On Fri, Aug 30, 2019 at 4:08 PM Dawid Wysakowicz
wrote:
> Hi,
>
> Ad. 1
>
> The advantage of our approach is that you have the type definition close
> to the option definition. The only difference is
Hi Chesnay,
You are right. FLIP-36 actually has not passed the vote yet. In fact some
of the key designs may have to change due to the later code changes. I'll
update the wiki and start a new vote.
Thanks,
Jiangjie (Becket) Qin
On Fri, Aug 30, 2019 at 8:44 PM Chesnay Schepler wrote:
iguration()
though. It seems indicating the Configurable is mutable, which might be
dangerous.
Thanks,
Jiangjie (Becket) Qin
On Fri, Aug 30, 2019 at 10:04 PM Timo Walther wrote:
> Hi Becket,
>
> 1. First of all, you are totally right. The FLIP contains a bug due to
> the last minu
+1. The new behavior makes sense to me.
BTW, we need a FLIP for this :)
On Fri, Aug 30, 2019 at 10:17 PM Till Rohrmann wrote:
> After an offline discussion with Stephan, we concluded that changing the
> default restart strategy for batch jobs is not that easy because the
> cluster level restart
+1
It is extremely useful for ML users.
On Mon, Sep 2, 2019 at 9:46 AM Shaoxuan Wang wrote:
> +1 (binding)
>
> This will be a great feature for Flink users, especially for the data
> science and AI engineers.
>
> Regards,
> Shaoxuan
>
>
> On Fri, Aug 30, 2019 at 1:35 PM Jeff Zhang wrote:
>
> >
m I missing something?
Thanks,
Jiangjie (Becket) Qin
On Mon, Sep 2, 2019 at 4:47 PM Dawid Wysakowicz
wrote:
> Hi Timo, Becket
>
> From the options that Timo suggested for improving the mutability
> situation I would prefer option a) as this is the more explicit option
> and simple
consider the following:
1. Design the Config mechanism as a cross-board API for not only internal
usage, but for broader use cases.
2. If writeToConfiguration is only for internal use cases, maybe we can
avoid adding it to the configurable interface. We can add another interface
such as Extract
ll be shortly changed by the follow-up FLIPs.
Thanks,
Jiangjie (Becket) Qin
On Tue, Sep 3, 2019 at 8:47 PM Aljoscha Krettek wrote:
> Hi,
>
> I think it’s important to keep in mind the original goals of this FLIP and
> not let the scope grow indefinitely. As I recall it, the goals ar
order to start the voting process. Any idea on how to make this work?
Thanks,
Jiangjie (Becket) Qin
On Thu, Jul 11, 2019 at 12:29 PM Yu Li wrote:
> Thanks for the summary and bring the discussion to public again Becket!
>
> Looking through the whole thread I think later discussion ha
create a new ExecutionConfig and put it
into the *confData* map Map? If not, the Configuration
instance will only contain primitive types, List or
Map. Then I have no concern on this part, because from
Configuration instance's perspective, it is immutable.
Thanks,
Jiangjie (Becket) Qin
O
(Becket) Qin
On Wed, Sep 4, 2019 at 4:32 PM Chesnay Schepler wrote:
> I'm quite worried that we may end up repeating history.
>
> There were already 2 attempts at contributing a pulsar connector, both
> of which failed because no committer was getting involved, despite the
> c
ted.
Can you check if your setting falls in one of the two cases?
Thanks,
Jiangjie (Becket) Qin
On Wed, Sep 4, 2019 at 9:03 PM Dominik Wosiński wrote:
> Hey,
> I was wondering whether something has changed for KafkaConsumer, since I am
> using Kafka 2.0.0 with Flink and I wanted
ng like ConfigPojo in order to avoid misuse as much
as possible.
Thanks,
Jiangjie (Becket) Qin
On Wed, Sep 4, 2019 at 5:50 PM Dawid Wysakowicz
wrote:
> Hi Becket,
>
> You are right, that what we had in mind for
> ExecutionConfig/CheckpointConfig etc. is the option b) from your email
ee if it would
fit in FLIP-27. It would be good to avoid the case that we checked in the
Pulsar connector with some review efforts and shortly after that the new
Source interface is ready.
Thanks,
Jiangjie (Becket) Qin
On Thu, Sep 5, 2019 at 8:39 AM Yijie Shen wrote:
> Thanks for all the
No, I don't think so.
As long as you have a successful checkpoint, The offset will be committed.
Thanks,
Jiangjie (Becket) Qin
On Thu, Sep 5, 2019 at 4:56 PM Dominik Wosiński wrote:
> Hey,
> Yeah I am using the first case. Is there a specific requirement for
> checkpoints ? Lik
we can jump to the new source interface. As long as we make
sure Flink 1.10 has it, waiting a little bit doesn't seem to hurt much.
Thanks,
Jiangjie (Becket) Qin
On Thu, Sep 5, 2019 at 3:59 PM Till Rohrmann wrote:
> Hi everyone,
>
> I'm wondering what the problem would be
Congrats, Kostas!
On Sun, Sep 8, 2019 at 11:48 PM myasuka wrote:
> Congratulations Kostas!
>
> Best
> Yun Tang
>
>
>
> --
> Sent from: http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/
>
, one for Pulsar sink and another for
Pulsar source. And we can start the work on Pulsar sink right away.
Thanks,
Jiangjie (Becket) Qin
On Mon, Sep 9, 2019 at 4:13 PM Sijie Guo wrote:
> Thank you Bowen and Becket.
>
> What's the take from Flink community? Shall we wait for
would be good to avoid
introducing a new connector with the same problem.
Thanks,
Jiangjie (Becket) Qin
On Tue, Sep 10, 2019 at 6:51 PM Stephan Ewen wrote:
> Hi all!
>
> Nice to see this lively discussion about the Pulsar connector.
> Some thoughts on the open questions:
>
>
Congrats, Zili!
On Thu, Sep 12, 2019 at 9:39 AM Paul Lam wrote:
> Congratulations Zili！
>
> Best,
> Paul Lam
>
> 在 2019年9月12日，09:34，Rong Rong 写道：
>
> Congratulations Zili!
>
> --
> Rong
>
> On Wed, Sep 11, 2019 at 6:26 PM Hequn Cheng wrote:
>
>> Congratulations!
>>
>> Best, Hequn
>>
>> On Thu,
ed in one or two months earlier.
Thanks,
Jiangjie (Becket) Qin
On Thu, Sep 12, 2019 at 3:52 PM Stephan Ewen wrote:
> Agreed, if we check in the old code, we should make it clear that it will
> be removed as soon as the FLIP-27 based version of the connector is there.
> We should
is that users may need to deal with another set of API, but that
seems OK.
So for this FLIP, it would be good to see whether we think motivation 1 is
worth addressing or not.
What do you think?
Thanks,
Jiangjie (Becket) Qin
On Thu, Aug 15, 2019 at 11:42 PM Stephan Ewen wrote:
> Sorry
FLIP
number collision. Can you change the FLIP number to 72?
Thanks,
Jiangjie (Becket) Qin
On Thu, Sep 19, 2019 at 12:23 AM Rong Rong wrote:
> Hi Yijie,
>
> Thanks for sharing the pulsar FLIP.
> Would you mind enabling comments/suggestions on the google doc link? This
> way the co
be a release manager of the Flink 2.0 release.
Cheers,
Jiangjie (Becket) Qin
On Tue, Apr 25, 2023 at 7:53 PM Leonard Xu wrote:
> Thanks Xintong and Jark for kicking off the great discussion!
>
> The time goes so fast, it is already the 10th anniversary of Flink as an
> Apache pr
Thanks for the FLIP, Archit.
The motivation sounds reasonable and it looks like a straightforward
proposal. +1 from me.
Thanks,
Jiangjie (Becket) Qin
On Fri, May 12, 2023 at 1:30 AM Archit Goyal
wrote:
> Hi all,
>
> I am opening this thread to discuss the proposal to support Yar
+1 (binding)
Thanks for driving the FLIP, Archit.
Cheers,
Jiangjie (Becket) Qin
On Tue, Jun 6, 2023 at 4:33 AM Venkatakrishnan Sowrirajan
wrote:
> Thanks for starting the vote on this one, Archit.
>
> +1 (non-binding)
>
> Regards
> Venkata krishnan
>
>
> On Mon, Ju
deprecated API can be
removed from the source code. So with this FLIP, I'd like to kick off the
discussion about our deprecation process.
https://cwiki.apache.org/confluence/display/FLINK/FLIP-321%3A+Introduce+an+API+deprecation+process
Comments are welcome!
Thanks,
Jiangjie (Becket) Qin
[
d migration to move to the new API.
3. upgrade to later Flink versions in which the code of the deprecated API
is removed.
So, it looks like our story for API stability and compatibility would be
complete with this FLIP.
Thanks,
Jiangjie (Becket) Qin
On Tue, Jun 13, 2023 at 12:30 AM Stefan Richt
the previous major version, which
likely introduces non-trivial burdens. If users want new features, they
should upgrade to 2.x.
Thanks,
Jiangjie (Becket) Qin
On Tue, Jun 13, 2023 at 10:24 PM Chesnay Schepler
wrote:
> On 13/06/2023 12:50, Jing Ge wrote:
> > One major issue we have, afai
gration period in the connectors as
the flink core, if the connectors are upgraded to the latest version of
core promptly.
Thanks,
Jiangjie (Becket) Qin
[1]
https://nightlies.apache.org/flink/flink-docs-master/api/java/deprecated-list.html
On Wed, Jun 14, 2023 at 1:15 AM Jing Ge wrote:
&
an choose to bump up
the major version to 3.0 at some point after the migration period has
passed, assuming by then most of the users have migrated away from the
deprecated Public API.
Thanks,
Jiangjie (Becket) Qin
On Wed, Jun 14, 2023 at 4:10 PM Xintong Song wrote:
> Thanks for bringing up
, and
even fix bugs in the old consumer, so additional maintenance effort is
required. But this allows the users to keep up with Kafka releases which is
extremely rewarding.
Thanks,
Jiangjie (Becket) Qin
On Wed, Jun 14, 2023 at 5:06 PM Matthias Pohl
wrote:
> Thanks for starting this discuss
e, I would rather bump up the major version again to remove the
deprecated Public API. That seems simpler and does not complicate the well
established versioning semantic conventions.
Thanks,
Jiangjie (Becket) Qin
On Wed, Jun 14, 2023 at 9:27 PM Matthias Pohl
wrote:
> One (made-up) example fr
tenance overhead for us
as Flink maintainers. When there is a conflict and no way around, having
some trade-off is reasonable. However, in this particular case, there seems
no material benefit of having a stability demotion process while it does
weaken the user experience.
Thanks,
Jiangjie (Becket) Q
ne.
Thanks again for raising these examples. This is a good discussion, as we
are getting to some root causes of our hesitation about the API stabilities.
Thanks,
Jiangjie (Becket) Qin
On Fri, Jun 16, 2023 at 10:13 AM Xintong Song wrote:
> Public API is a well defined common concept, and o
lose the Public API
anyways and a major version bump ensures there is no surprise.
Thanks,
Jiangjie (Becket) Qin
On Fri, Jun 16, 2023 at 10:13 AM Xintong Song wrote:
> Public API is a well defined common concept, and one of its
>> convention is that it only changes with a major version
rtable with the maintenance overhead of deprecated APIs, we can
then have a stronger guarantee for Experimental / PublicEvolving APIs.
Thanks,
Jiangjie (Becket) Qin
On Sun, Jun 18, 2023 at 6:44 AM John Roesler wrote:
> Hi Becket,
>
> Thanks for this FLIP! Having a deprecation proces
is if we are willing to have a migration
period, and do a minor version bump to remove an API, what do we lose to do
a major version bump instead, so we don't break the common versioning
semantic?
Thanks,
Jiangjie (Becket) Qin
On Mon, Jun 19, 2023 at 3:20 PM Xintong Song wrote:
> >
the
releases.
So, if there are concrete examples that you think will block us from
keeping API stability with affordable cost, let's take a look together and
see if that can be improved.
Thanks,
Jiangjie (Becket) Qin
>From what I see,
On Mon, Jun 19, 2023 at 4:45 PM Xintong Song
Thanks much for the input, John, Stefan and Jing.
I think Xingtong has well summarized the pros and cons of the two options.
Let's collect a few more opinions here and we can move forward with the one
more people prefer.
Thanks,
Jiangjie (Becket) Qin
On Wed, Jun 21, 2023 at 3:20 AM Ji
nally speaking, I don't feel this assumption is necessarily true. We
should re-evaluate once we have the new ProcessFunction API in place.
Without the code it is hard to tell for sure. I am actually kind of
optimistic about the maintenance cost.
Thanks,
Jiangjie (Becket) Qin
On Sun, Jun 25, 2023 a
that to the
FLIP wiki. This is probably more of a clarification on the existing
convention, rather than a change.
It looks like we are on the same page now for this FLIP. If so, I'll start
a VOTE thread in two days.
Thanks,
Jiangjie (Becket) Qin
On Mon, Jun 26, 2023 at 8:09 PM Xintong Song
es.
+1 on having toolings to enforce the conventions.
Thanks,
Jiangjie (Becket) Qin
On Wed, Jun 28, 2023 at 5:09 AM Martijn Visser
wrote:
> Hi all,
>
> Thanks for the lively and good discussion. Given the length of the
> discussion, I skimmed through and then did a deep dive on the
Hi folks,
I'd like to start the VOTE for FLIP-321[1] which proposes to introduce an
API deprecation process to Flink. The discussion thread for the FLIP can be
found here[2].
The vote will be open until at least July 4, following the consensus voting
process.
Thanks,
Jiangjie (Becket) Qi
Thanks everyone for voting.
We have got 11 approving votes and no disapproving votes. FLIP-321 has now
passed!
The voting details are following:
9 binding votes:
Dong Lin
Xintong Song
Martijn Visser
Stefan Richter
Jing Ge
Matthias Pohl
Zhu Zhu
Jingsong Li
Becket Qin
2 non-binding votes
, DataType
producedDataType)
This will need a FLIP.
Thanks,
Jiangjie (Becket) Qin
On Tue, Aug 1, 2023 at 11:42 PM Venkatakrishnan Sowrirajan
wrote:
> Thanks for the response. Looking forward to your pointers. In the
> meanwhile, let me figure out how we can implement it. Will keep you
don't have to address it right away
in the same FLIP, this kind of debt accumulates over time and makes the
project harder to learn and maintain. So, personally I prefer to address
these technical debts as soon as possible.
Thanks,
Jiangjie (Becket) Qin
On Wed, Aug 2, 2023 at 8:19 PM Jark Wu
r not, e.g. batch mode, processing time
only jobs, etc.
Thanks,
Jiangjie (Becket) Qin
On Fri, Aug 11, 2023 at 9:46 PM Dong Lin wrote:
> Hi Xintong,
>
> Thanks for the quick reply. I also agree that we should hear from others
> about
> whether this optimization is worthwhile.
>
&
configuration controlling the client side behavior, instead of the
execution of the job.
Thanks,
Jiangjie (Becket) Qin
On Thu, Aug 10, 2023 at 10:34 PM Weihua Hu wrote:
> Hi Allison
>
> Thanks for driving this FLIP. It's a valuable feature for batch jobs.
> This helps keep "Drop P
r the use
cases that the optimization helps are important enough. And this judgement
is somewhat subjective.
Thanks,
Jiangjie (Becket) Qin
On Mon, Aug 14, 2023 at 9:13 PM Jark Wu wrote:
> Hi Becket,
>
> > I kind of think that we can
> restrain the scope to just batch mode, and o
on. So, in fact, the execution.attached configuration is only
honored by the client, but not the cluster. Therefore, I think removing it
makes sense.
Thanks,
Jiangjie (Becket) Qin
On Thu, Aug 17, 2023 at 12:31 AM liu ron wrote:
> Hi, Jiangjie
>
> Sorry for late reply. Thank you for such a detailed
prefer this alternative. It takes longer to finish the work,
but the API eventually becomes clean and consistent. But I can live with
the current proposal.
Thanks,
Jiangjie (Becket) Qin
On Sat, Aug 19, 2023 at 12:09 AM Venkatakrishnan Sowrirajan <
vsowr...@asu.edu> wrote:
> Gentle
I
prefer the latter if we are designing from scratch. It is clean, consistent
and intuitive. Given the size of Flink, keeping APIs in the same style over
time is important. The migration is also not that complicated.
Thanks,
Jiangjie (Becket) Qin
On Tue, Aug 22, 2023 at 2:23 PM Jark Wu wrote:
&
1 - 100 of 467 matches
Mail list logo
