Re: Code ownership over the provider's source code

Let's see how it plays out with GitHub. If this does not work, we could potentially extend boring cyborg to add some notifications or do something similar. I think until we get the answer (hopefully that it works) we should really discuss and decide as a community how we approach providers we

[ANNOUNCEMENT] New Airflow Providers released on Mon 11 Apr

Dear community, I'm happy to announce that new versions of Airflow Providers packages were just released. The mission of Apache Airflow is the creation and maintenance of software related to workflow automation and scheduling that can be used to author and manage data pipelines. Airflow

Re: [ANNOUNCEMENT] Feel the (new) breeze

Very cool. Can't wait to play around with it. Congrats and thanks to Bowrna, Edith, and their mentoring team! From: Jarek Potiuk Sent: Sunday, April 10, 2022 12:19 PM To: dev@airflow.apache.org Subject: [EXTERNAL] [ANNOUNCEMENT] Feel the (new) breeze

Re: Code ownership over the provider's source code

> BTW. Seems that there is a problem that you STILL need write access to be > CODEOWNER (despite the updated documentation :) ) Sad, I was also very excited about this. It would make the workflow of keeping an eye on changes to code we "own" much easier. Fingers crossed it's a feature coming

[RESULT][VOTE] Airflow Providers - release of April 07, 2022

Hey all, Apache Airflow Providers (based on RC1) have been accepted (except Databricks provider that had a serious bug and RC2 follows shortly). 3 “+1” binding votes received: - Jarek Potiuk (binding) - Jed Cunningham (binding) - Ephraim Anierobi (binding) 1 " +1 non-binding vote received: -

Re: Code ownership over the provider's source code

This would be very nice. I try to keep an eye on any PR related to the AWS provider package, getting a ping would certainly be convenient and less prone to "how the heck is it already {foo}, where did the time/day/week go!?!?" user errors :P From: Jarek

Re: [DISCUSS] Approach for new providers of the community

I've been thinking about it - to make up my mind a little. The good thing for me is that I have no strong opinion and I can rather easily see (or so I think) of both sides. TL;DR; I think we need an explanation from the "Service Providers" - what they want to achieve by contributing providers to

Re: [ANNOUNCEMENT] Feel the (new) breeze

very cool 

Re: [DISCUSSION] Adding a new provider: Flyte

To help people get started down this path one of the teams at Astronomer have created and then if you'd like (it's entirely optional) you can submit it to the Astronomer Registry <> via

Re: [DISCUSSION] Adding a new provider: Flyte

+1 -- I agree with Max & Rafal that this should be a provider living in a separate repo and maintained by Flyte (if possible) so you can quickly and easily make changes when you update your APIs. Regards, Kaxil On Sun, 10 Apr 2022 at 13:04, Rafal Biegacz wrote: > Samhita & Max, > > Maybe a

Re: [ANNOUNCEMENT] Feel the (new) breeze

This is awesome. Keep up the good work Edith and Bowrna. On Mon, Apr 11, 2022 at 13:00 Elad Kalif wrote: > Great work Bowrna and Edith! > > On Mon, Apr 11, 2022 at 11:54 AM Rafal Biegacz > wrote: > >> Jarek, Bowrna and Edith - way to go and thank you! :) >> >> Regards, Rafal. >> >> On Sun, Apr

Re: [ANNOUNCEMENT] Feel the (new) breeze

Great work Bowrna and Edith! On Mon, Apr 11, 2022 at 11:54 AM Rafal Biegacz wrote: > Jarek, Bowrna and Edith - way to go and thank you! :) > > Regards, Rafal. > > On Sun, Apr 10, 2022 at 9:19 PM Jarek Potiuk wrote: > >> Hey everyone, >> >> Feel the (new) breeze - written in Python. >> >> I

Re: Code ownership over the provider's source code

BTW. Seems that there is a problem that you STILL need write access to be CODEOWNER (despite the updated documentation :) ) https://github.com/apache/airflow/pull/22903 I hope it's just "future documentation" :) and this feature is being released now (or maybe just the error message is outdated)

Re: Code ownership over the provider's source code

Yes, you worded it perfectly - I don't intend to be the owner of the code (and in any way gatekeeping it) but merely improve how we're notifying on code changes (or assigning to code review). I listed my PR as an example but it was a question in general - where I see that there could be people

Re: Code ownership over the provider's source code

I think you are both right and both wrong - Elad and Bartłomiej :) Elad is quite right when it comes to "gating" changes. You might get notified about a change and raise your concerns but the nature of ASF project is simple - committers decide whether a change is ready. Any commiter (and

Re: Code ownership over the provider's source code

> Committers can merge PRs as they see fit. We don't have to wait for a specific code owner. I must disagree with you. I know how open source projects works (I'm the maintainer of some) but in Airflow the problem is different. We have multiple providers that are responsible for their code but

Re: Code ownership over the provider's source code

Hi Bartłomiej, Due to the nature of the project multiple authors can work on the same files and not even know one to another. GitHub doesn't offer a feature to let the PR author know that there are other open PRs requesting to change the same file. In general this is not "Priority to who opens

Re: Code ownership over the provider's source code

This is a very good point :) and has surprising (at least to me) answer: We have two mechanisms now: * Labels by Boring Cyborg (not very helpful as you cannot selectively subscribe to a label): https://github.com/apache/airflow/blob/main/.github/boring-cyborg.yml * CODEOWNERS feature (this one

Code ownership over the provider's source code

Hi, Do we have any mechanism in Airflow to be notified on PRs touching provider code hosted in the Airflow repository? I think that's not the case - and it's related to recent discussions about providers in the core repository (on dev list). I've had some problems in the past where I discovered