Hello, @Robert Metzger<mailto:rmetz...@apache.org> thanks for creating the repo [1]. I have not yet populated it yet; I will spend time of this after my summer vacation.
I wanted to raise a concern around the http connector. I am aware that there are many Flink connectors and only some of them have released versions for Flink 1.20 and even less work with Flink 2.0. I do not want this to be the fate of the http connector. In order to avoid this and to have a healthy connector going forward, I think we need the interested parties to have write access to this repository. Specifically, we should grandfather in the GetInData committers (full disclosure I am one of these committers) as committers for this repository. This would mean there would be motivated , interested people who would be responsible (and accountable) to improve, fix and release this connector. How might we justify this, as the people are unknown to the Flink community: * We have already accepted the connector with their work in as a Flink contribution * We will bring in the commits in the git history so these could be viewed as Apache contributions. * Is there a risk in doing this? Yes, but I think there is a bigger risk in not doing this. It seems to be a choice between a viable community around this repo or another under resourced connector repo, with existing Flink committers not being familiar or motivated to spend time with the repo. So merging in PRs and creating releases will not be done in a timely way. In the spirit of community over code, I think we should bring in the GetInData committers as Flink committers, enhancing the community to ensure that this is a healthy connector going forward and it gets the love it deserves! Other connectors that are not getting Flink 1.20 and v2 releases will also need a group of committers to ensure that they get released; if there is not an identifiable group of people to keep these connectors healthy, I suggest we look to mothball (remove the docs from Flink master) these connectors until such time that there are committers that can support them. Also, I like the idea[2] Danny raised. We can try this with the HTTP connector. Thoughts? Kind regards, David. [1] https://github.com/apache/flink-connector-http [2] https://lists.apache.org/thread/byy8fgkr8dbrrdv2nxpxkrz18h904r9b From: Robert Metzger <rmetz...@apache.org> Date: Tuesday, 8 July 2025 at 07:07 To: dev@flink.apache.org <dev@flink.apache.org> Subject: [EXTERNAL] Re: [RESULT][VOTE] Flip-532 Donate GetInData HTTP Connector to Flink voila: https://github.com/apache/flink-connector-http/tree/main On Tue, Jul 8, 2025 at 7:49 AM Robert Metzger <metrob...@gmail.com> wrote: > Hey, > > @Sergey: Thanks for your message. Which other HTTP connector are you > referring to? > Changing the bylaws requires a 2/3 majority. We can clarify the wording > next time we need to make changes (I left a comment on that page). > > @David: I will create the repo now > > > On Mon, Jul 7, 2025 at 11:04 AM David Radley <david_rad...@uk.ibm.com> > wrote: > >> Hi Sergey, >> Thanks for your thoughts on this. >> >> I guess we could go some sort of retrospective to understand how >> consistently the 2/3 majority was applied. >> It is probably better to clarify the words – as you suggest. My take is >> we should look to have the minimal admin and process to get things through >> in a timely manner; where this is not appropriate is when some proposal >> fundamentally changes Flink – these changes need proper consideration, and >> the 2/3 majority would apply. I suggest the 2/3 majority should only be >> used when necessary and should not be overused. >> >> Maybe a clarification could be along the lines of - If any member of the >> PMC thinks that a Flip is sufficiently disruptive, they should propose that >> the 2/3s majority be used. Would this help? >> >> Kind regards, David. >> >> From: Sergey Nuyanzin <snuyan...@gmail.com> >> Date: Monday, 7 July 2025 at 09:21 >> To: dev@flink.apache.org <dev@flink.apache.org> >> Subject: [EXTERNAL] Re: [RESULT][VOTE] Flip-532 Donate GetInData HTTP >> Connector to Flink >> Hi Robert and David >> >> Thank you for your clarifications. >> >> I'm not going to block or veto it, I have just raised a concern that >> from one side there is an example with CDC connectors and from another >> HTTP connector and they are handled differently. >> >> If you think it is ok, I'm fine with it. >> >> Maybe then we should add more clarifications about that in Flink >> bylaws or some other place? >> >> On Fri, Jul 4, 2025 at 6:34 PM David Radley <david_rad...@uk.ibm.com> >> wrote: >> > >> > Hi Sergey and Robert, >> > In the Community Health Initiative workgroup we had discussed this and >> Robert mentioned his line of thinking that this would need 3 votes rather >> than the 2/3s of PMC. >> > I agree with Robert when he says : >> > >> > I don't think a new connector changes the shape and direction of the >> > project ? >> > It's "just" a major change, requiring a FLIP. >> > >> > Saying that, we have only received support this Flip. I would love to >> hear any specific concerns about this connector. It is not perfect and >> could be more complete and will be further enhanced, but is it a big value >> add for many use cases as-is. >> > Kind regards, David. >> > >> > >> > >> > From: Robert Metzger <rmetz...@apache.org> >> > Date: Thursday, 3 July 2025 at 07:27 >> > To: dev@flink.apache.org <dev@flink.apache.org> >> > Subject: [EXTERNAL] Re: [RESULT][VOTE] Flip-532 Donate GetInData HTTP >> Connector to Flink >> > Hey Sergey, >> > >> > I thought about this question as well, but in my opinion, a regular 3 >> > binding PMC vote is sufficient here: >> > >> > The description of a new codebase adoption is: >> > >> > > Adoption of large existing external codebase. This refers to >> contributions >> > > big enough that potentially change the shape and direction of the >> project >> > > with massive restructuring and future maintenance commitment. >> > >> > >> > I don't think a new connector changes the shape and direction of the >> > project ? >> > It's "just" a major change, requiring a FLIP. >> > >> > For me, the biggest concern with any new connector will be the lack of >> an >> > active community around it. People willing to fix, review, release >> stuff. >> > However, I did not bring this up, since two companies (IBM, GetInData) >> seem >> > to be actively using it, and the GH community is fairly active. >> > I understand the desire of companies to make contributions to >> repositories >> > that are maintained by an independent organization (Apache), instead of >> a >> > company (GetInData), that's why I support this FLIP. >> > If you feel otherwise, you as a PMC member have the power to stop this >> > effort, if you think it requires further discussion in the PMC. >> > >> > Best, >> > Robert >> > >> > >> > On Tue, Jul 1, 2025 at 8:17 AM Sergey Nuyanzin <snuyan...@gmail.com> >> wrote: >> > >> > > Thank you for your volunteering here David >> > > >> > > I don't want to be a devil's advocate however I'm not sure we can >> > > consider it as a regular FLIP and accepted. >> > > The reason I think this way is the current Flink Bylaws[1] and >> > > especially telling that in case of "Adoption of New Codebase" >> > > we need to achieve 2/3 majority of votes in order to accept it. The >> > > similar thing happened while accepting CDC Flink connectors [3]. >> > > Also binding votes in this cases are considered not the same way as >> > > for regular FLIPs >> > > >> > > Please correct me if I'm wrong >> > > >> > > [1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws >> > > [2] >> > > >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026#FlinkBylaws-Actions >> > > [3] https://lists.apache.org/thread/sq5w21tcomrmb025tl820cxty9l0z26w >> > > >> > > On Mon, Jun 30, 2025 at 3:48 PM David Radley <david_rad...@uk.ibm.com >> > >> > > wrote: >> > > > >> > > > Hi devs, >> > > > >> > > > The vote[1] on FLIP-532[2] concluded with the following results: >> > > > >> > > > Approving(+1) votes: >> > > > >> > > > Ferenc Csaky (binding) >> > > > Gyula Fora (binding) >> > > > Leonard Xu (binding) >> > > > >> > > > >> > > > >> > > > PoorVank Bhatia (non-binding) >> > > > >> > > > Sharath (non-binding) >> > > > Nic Townsend (non-binding) >> > > > >> > > > Lajith Koova (non-binding) >> > > > >> > > > Tom Cooper (non-binding) >> > > > >> > > > Mark Nuttall (non-binding) >> > > > >> > > > Anu K T (non-binding) >> > > > >> > > > Mehdi Deboub (non-binding) >> > > > >> > > > Ammu P (non-binding) >> > > > >> > > > Sebastien Pereira (non-binding) >> > > > >> > > > >> > > > >> > > > >> > > > There were 3 binding, 10 non-binding and no disproving(-1) votes. >> > > > >> > > > I'm happy to announce that FLIP-532 has been approved. >> > > > >> > > > Thanks, >> > > > David >> > > > >> > > > [1] >> https://lists.apache.org/thread/ft7cw2cy7g5cj3hyx6l9r1twnoy0wr0q >> > > [2] >> > > >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-532%3A+Donate+GetInData+HTTP+Connector+to+Flink >> > > > >> > > > >> > > > Unless otherwise stated above: >> > > > >> > > > IBM United Kingdom Limited >> > > > Registered in England and Wales with number 741598 >> > > > Registered office: Building C, IBM Hursley Office, Hursley Park >> Road, >> > > Winchester, Hampshire SO21 2JN >> > > >> > > >> > > >> > > -- >> > > Best regards, >> > > Sergey >> > > >> > >> > Unless otherwise stated above: >> > >> > IBM United Kingdom Limited >> > Registered in England and Wales with number 741598 >> > Registered office: Building C, IBM Hursley Office, Hursley Park Road, >> Winchester, Hampshire SO21 2JN >> >> >> >> -- >> Best regards, >> Sergey >> >> Unless otherwise stated above: >> >> IBM United Kingdom Limited >> Registered in England and Wales with number 741598 >> Registered office: Building C, IBM Hursley Office, Hursley Park Road, >> Winchester, Hampshire SO21 2JN >> > Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN