There are no more comments, I will merge this one (already approved). It's more of a reflection of what we already discussed and agreed on before, but if there are more comments/wording corrections etc, I am happy to iterate on that one later.
On Sat, Apr 15, 2023 at 12:49 PM Jarek Potiuk <[email protected]> wrote: > Also - I always like those kinds of policies to work on examples. And we > have a cool one. > > I added a proposed rule to make it easier a bit when we are accepting a > new provider, that is about not a service managed by a 3rd-party. This > is when we have another open-source software integration. In particular, > when such open-source software has governance by Apache Software Foundation > or similar foundation with good governance, I propose that such a provider > (when PR is of a great quality). LAZY CONSENSUS should be enough to accept > such a provider. > > We have now a great example - Dylan from Astronomer had just completed > iteration on Apache Kafka Provider PR (donated by Astronomer and for a long > time tested and proven with their providers package) and it has precisely > the kind of quality we - I think - need to be able to accept such provider, > That is including integration test that make it easy to setup Kafka with > breeze and run tests with the real "Kafka" running in a docker-compose > managed setup. I will call for a LAZY CONSENSUS there - and if that will be > cool for everyone, we can treat it as a precedent for similar cases in the > future. > > J. > > > On Sat, Apr 15, 2023 at 9:56 AM Jarek Potiuk <[email protected]> wrote: > >> Hello Everyone, >> >> I prepared a PR, where I tried to capture the results of all discussions >> of the community/3rd-party providers >> >> https://github.com/apache/airflow/pull/30657 >> >> This is just a proposal for now - and since English is not my >> native language (and I am known to write too many words rather than too >> little), I am happy to get the comments and corrections, and updates to the >> PR. The aim of this page is to explain once and for all what is our >> approach to accepting new providers, explaining what are the consequences >> of having a community vs. 3rd-party provider so that everyone can be aware >> of it without reading long devlist discussions we had about it, >> >> Part of this PR is extracting what we had so far in README to separate >> PROVIDERS.rst file - which I think is a better place as the small chapter >> about providers outgrew the README already (which should be small and >> concise). >> >> Take your time in reviewing and commenting on it. I think it is important >> to make it precise and clear. Anyone is welcome to contribute. >> >> J. >> >>
