Good point. Discussion for each new connector is also an overhead we should avoid.
IMHO, option #2 doesn’t seem like a reasonable staging area. Say we decide we’d like to move a connector from Bahir to Flink in the future, there’ll be two of the connector in separate Apache projects. Personally I think option #2 is more like a way to go if some day we’d like to migrate some of our currently supported connectors in Flink to Bahir (perhaps an alternative to the discussion in "Externalizing the Flink connectors”). Defining option #1 as a staging area seems nice; the contributor notifies the Flink community of the work by adding it to the 3rd party packages page, and in the future we can contact the contributor to ask whether they’d like to migrate the connector to Flink when we see more user demand and committer support. With this approach, do you think we should assume that future new connectors always go to option #1 first? If not, I would assume that in the future, Flink JIRAs for new connectors are only opened if we’d like to add them directly to Flink (perhaps the contribution guideline can link to Flink development Roadmaps like [1] as a reference to connectors that the community has already considered to support?). [1] https://docs.google.com/document/d/1ExmtVpeVVT3TIhO1JoBpC5JKXm-778DAD7eqw5GANwE/edit# <https://docs.google.com/document/d/1ExmtVpeVVT3TIhO1JoBpC5JKXm-778DAD7eqw5GANwE/edit> On August 9, 2016 at 6:10:21 PM, Robert Metzger (rmetz...@apache.org) wrote: Hi Gordon, thank you for your response. I agree with your observation that some "staging" area is helpful to test how many contributors / users are interested in a connector. But I wonder if #1 or #2 can also serve as a staging area: As soon as we see that there is a lot of interest in a connector, we add it to the main "flink-*-connectors" directory. Having too many ways to contribute connectors might make the discussions for each new connector quite complicated. You are right, the intention of the "Externalizing the Flink connectors” discussion was more about the release intervals, test time etc. Regards, Robert
