Re: [VOTE] AIP-67 Multi-team deployment of Airflow components

This is exciting. +1 binding. - ferruzzi From: Oliveira, Niko Sent: Thursday, April 18, 2024 9:16 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-67 Multi-team deployment of Airflow components CAUTION: This email

Re: [ANNOUNCE] New committer: Wei Lee

Congrats, and welcome! - ferruzzi From: Tomasz Urbaszek Sent: Monday, April 8, 2024 12:42 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [ANNOUNCE] New committer: Wei Lee CAUTION: This email originated from outside of the

Re: [DISCUSS] Consider disabling self-hosted runners for commiter PRs

Interested in seeing the difference, +1 - ferruzzi From: Oliveira, Niko Sent: Thursday, April 4, 2024 2:00 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [DISCUSS] Consider disabling self-hosted runners for commiter PRs CAUTION:

Re: [DISCUSS] Rename channels on slack

I'm all for the shorter names. I can never understand why so many people ask the questions they do in #development, its purpose seems pretty obvious to me but perhaps a rename is good for it; I'm -0 on that one. I also agree that #troubleshooting is clear and nothing is gained from making it

Re: [VOTE] AIP 61 - Hybrid Executors

+1 binding - ferruzzi From: Igor Kholopov Sent: Thursday, February 1, 2024 5:31 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP 61 - Hybrid Executors CAUTION: This email originated from outside of the organization. Do not

Re: [ANNOUNCE] Starting experimenting with "Require conversation resolution" setting

So far, my only real down side is that sometimes discussions happen in comments (not in threaded code comments, but in one-off "add a comment" comments) which this doesn't capture and they are annoying to track. While that isn't an actual issue with this CI change, this change may possibly

Re: [DISCUSS] "Require conversation resolution" in our PRs before merge?

Interesting. I generally try to follow that policy as a best practice on my own PRs just so I make sure I didn't miss comments, but there are also times I intentionally leave certain discussions "out in the open". I guess as long as we are not dictating that the person who left the comment

Re: [PROPOSAL] Security team rotation introduction to our process

I don't know that we'd need to make the shadow period too formal, we all come from diverse backgrounds.One of the reasons I didn't step up for the "full-time" position is that I have no real background in the security side of things and I didn't want to be a drain. But I'd consider a

Re: [DISCUSS] Suspend/Remove Apache Scoop provider

I'd like to see usage metrics if there are any (number of package downloads or something?) before deciding to drop it, but I'm pretty comfortable that this one is safe to remove given the project's history. +1 - ferruzzi From: Oliveira, Niko Sent:

Re: [DISCUSS] Suspend (Remove?) Daskexecutor provider

Just getting back from some time away, if it's till up for discussion, I'd vote for staged removal, the same as any other provider package being dropped. Perhaps the intermediate step might shake loose a user who cares enough to take it on. If not, we lose nothing but a little time. -

Re: AIP-49 OpenTelemetry call for action/help

off of. > > -- > Regards, > Aritra Basu > > On Fri, Oct 27, 2023, 9:35 PM Ferruzzi, Dennis > > wrote: > > > Hello friends! OTel support for metrics reporting has been live for a > bit > > now and I am looking forward to the next stage which will be to get &

AIP-49 OpenTelemetry call for action/help

Hello friends! OTel support for metrics reporting has been live for a bit now and I am looking forward to the next stage which will be to get Traces and Spans implemented. Howard Yoo has a working proof-of-concept for the Traces in the AIP, and I have set up a Project board on GitHub with a

Re: [VOTE] Add providers for Pinecone, OpenAI & Cohere to enable first-class LLMOps

+1 (binding) - ferruzzi From: Jed Cunningham Sent: Wednesday, October 25, 2023 9:54 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] Add providers for Pinecone, OpenAI & Cohere to enable first-class LLMOps CAUTION: This email

OpenTelemetry

SA1 submitted an Issue (https://github.com/apache/airflow/issues/34405) pointing out that is the connection to OTel fails for whatever reason, there is an exception thrown and the task fails, and proposing that we log/warn and carry on without emitting the metric. This requires a little bit of

Re: [DISCUSS] Executors docs should be published in Airflow core or providers?

I like it. - ferruzzi From: Jarek Potiuk Sent: Friday, September 8, 2023 9:19 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [DISCUSS] Executors docs should be published in Airflow core or providers? CAUTION: This email originated

Re: [VOTE] Drop MsSQL as supported backend

I was away on vacation and missed yesterday's deadline, but glad to see this. +1 - ferruzzi From: Elad Kalif Sent: Sunday, August 27, 2023 11:30 PM To: dev@airflow.apache.org Subject: [EXTERNAL] [VOTE] Drop MsSQL as supported backend CAUTION: This email

Re: [VOTE] Release Airflow 2.7.0 from 2.7.0rc2

Looks like the AWS provider package is happy and overall CI is happy. +1 non-binding - ferruzzi From: Utkarsh Sharma Sent: Wednesday, August 16, 2023 8:05 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [VOTE] Release Airflow 2.7.0 from 2.7.0rc2

Re: [VOTE] The daskexecutor, cncf.provider, celery providers in 2.7.0. as regular not-preinstalled providers

Pretty unanimous so far, but I'll also say [a]. If the intent is to be executor/service agnostic then this makes the most sense to me. - ferruzzi From: Jed Cunningham Sent: Monday, July 31, 2023 9:39 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL]

Re: [DISCUSS] Should we pre-install celery/k8s providers?

I really like the idea of having them all entirely separate and letting the user install which one(s) they want, there are a lot of good reasons for that which are already covered. I'll bring up one point that nags me about this change though. Airflow requires SOME executor. I agree we

Re: [DISCUSS] Moving Dask Executor to a separate (optional?) dask provider

I'm not sure how much of a train wreck it would turn into, but moving Dask Executor to a provider seems logical to me. Maybe in the far-flung future of Airflow 3.0 we could move celery and k8s into their own as well and make it truly pluggable and executor-agnostic, but I agree that at this

Re: [RESULT] [VOTE] Move K8S / Celery (and related) executors to respective providers

Nice - ferruzzi From: Jarek Potiuk Sent: Tuesday, July 11, 2023 9:52 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][RESULT] [VOTE] Move K8S / Celery (and related) executors to respective providers CAUTION: This email originated from outside of the

Re: [ANNOUNCE] New committer: Dennis Ferruzzi

Thanks everyone! > conngraatullationss!! *chef-kiss* - ferruzzi From: Akash Sharma <2akash111...@gmail.com> Sent: Tuesday, July 4, 2023 10:31 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][ANNOUNCE] New committer: Dennis Ferruzzi CAUTION: This email

Re: [VOTE] AIP-56 Extensible user management

Seems like a good solution to a feature a lot of folks want. non-binding +1 - ferruzzi From: Mehta, Shubham Sent: Monday, June 19, 2023 10:25 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][VOTE] AIP-56 Extensible user management CAUTION: This email

Re: Deferrable operators in system tests, how?

FWIW, I'm liking the Breeze idea. I hadn't thought of it at first, but it seems to make the most sense. - ferruzzi From: Beck, Vincent Sent: Wednesday, June 7, 2023 7:21 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL]Deferrable operators in system

Re: [PROPOSAL] Solidifying and improving security handling process for Airflow

Neat. I like the idea of expanding the membership to folks who have expertise in such things. Seems to make sense to me, we can't all be experts in everything. non-binding +1? - ferruzzi From: Jarek Potiuk Sent: Monday, May 8, 2023 11:31 PM To:

Re: [DISCUSS] Preparing for dropping Python 3.7 support

I am the walrus! := Looking forward to it, thanks for the update. - ferruzzi From: Kaxil Naik Sent: Thursday, May 4, 2023 5:40 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][DISCUSS] Preparing for dropping Python 3.7 support CAUTION: This email

Re: [ANNOUNCE] New committer Hussein Awala

Congrats! - ferruzzi From: Oliveira, Niko Sent: Tuesday, April 11, 2023 5:00 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][ANNOUNCE] New committer Hussein Awala CAUTION: This email originated from outside of the organization. Do not click links or

Re: [DISCUSS] Exclude some providers that hold us back from releasing

..@apache.org>> wrote: > > > > > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you can confirm the sender and know > > the content is safe. > > > > > > > > > > >

Re: [VOTE] March PR of the Month

Having poked at the KubernetesPodOperator in the past and knowing what a bear it is to work with, I'll throw my vote to 28336. - ferruzzi From: John Thomas Sent: Tuesday, March 28, 2023 11:04 AM To: dev@airflow.apache.org Subject: [EXTERNAL] [VOTE] March PR

Re: [DISCUSS] Exclude some providers that hold us back from releasing

I don't have any issue with this in general, in fact I think it's not a bad idea to trim out older unused/unmaintained providers. But what are the criteria for marking a provider package as unmaintained? Is it simply "once a package becomes a blocker AND nobody has stepped up to fix it in

Re: [DISCUSS] AIP-52 updates - setup / teardown tasks

> If the set-up ran then the short circuit shouldn't be able to skip it >> I think this is overly and unnecessarily opinionated and limiting. I would not be concerned with having the default be one way or another, but to say that "you should not be able to skip it", I disagree with the notion

Re: [DISCUSS] AIP-52 updates - setup / teardown tasks

the conversation at this stage. -ferruzzi From: Ferruzzi, Dennis Sent: Monday, March 27, 2023 12:43 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][DISCUSS] AIP-52 updates - setup / teardown tasks CAUTION: This email originated from outside of the organization. Do

Re: [DISCUSS] AIP-52 updates - setup / teardown tasks

I really like the idea of this AIP and I'm looking forward to seeing how you implement it. I know you've put lots of effort into it, and I'm not looking to derail your plans. It may be entirely too late at this point, but if you are doing a rework, how would you feel about the idea of the

Re: [AIP-49 OTel] [Discussion] Metrics Provider packages

s the documentation how to enable the > collector for CloudWatch and dependency to pull the cloudwatch > collector package. > > I hope what I am writing makes sense :). > > J. > > On Thu, Mar 9, 2023 at 10:42 PM Ferruzzi, Dennis > wrote: > > > > Hi folks

Re: [ANNOUNCE] New PMC member: Pierre Jeambrun

Congratulations! From: Jarek Potiuk Sent: Tuesday, March 14, 2023 5:52 PM To: dev@airflow.apache.org Subject: [EXTERNAL] [ANNOUNCE] New PMC member: Pierre Jeambrun CAUTION: This email originated from outside of the organization. Do not click links or open

Re: [ANNOUNCE] New PMC member: Brent Bovenzi

Nice, congrats! From: Jarek Potiuk Sent: Tuesday, March 14, 2023 5:49 PM To: dev@airflow.apache.org Subject: [EXTERNAL] [ANNOUNCE] New PMC member: Brent Bovenzi CAUTION: This email originated from outside of the organization. Do not click links or open

[AIP-49 OTel] [Discussion] Metrics Provider packages

Hi folks. I am working on adding support for OpenTelemetry based on AIP-49 and I think we have come to a point where it is worth discussing options. Currently `airflow/stats.py`[1] contains classes for a base/NoStats option as well as Statsd and DataDog, and I will be adding in another option

Re: The issue / PR no. 30000 !

*confetti* From: Jarek Potiuk Sent: Thursday, March 9, 2023 11:13 AM To: dev@airflow.apache.org Subject: [EXTERNAL] The issue / PR no. 3 ! CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you

Re: [LAZY CONSENSUS] Allow shorter voting periods for subsequent RCs

+1 (non-bindingly lazy) From: Pierre Jeambrun Sent: Tuesday, March 7, 2023 12:11 PM To: dev@airflow.apache.org Subject: [EXTERNAL] [LAZY CONSENSUS] Allow shorter voting periods for subsequent RCs CAUTION: This email originated from outside of the organization.

Re: [LAZY CONSENSUS] Unsubscribe links in users@ mailing list footers

+1 always a good idea From: Jarek Potiuk Sent: Thursday, March 2, 2023 11:24 PM To: dev@airflow.apache.org Subject: [EXTERNAL] [LAZY CONSENSUS] Unsubscribe links in users@ mailing list footers CAUTION: This email originated from outside of the organization. Do

Re: [VOTE] February PR of the Month

I'll vote for 058, just to be different :P From: Pankaj Singh Sent: Sunday, February 26, 2023 11:07 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][VOTE] February PR of the Month CAUTION: This email originated from outside of the organization. Do not

Re: [Discussion] DB backend versions policy

Very detailed, thanks.I think I want to lean towards whatever the official support for the package is and not measure ourselves by what the various SaaS options are doing. I think there will always be some cloud provider lagging or keeping some old legacy version alive well beyond it's

Re: [DISCUSSION] Move K8S and Celery Executors (and related) to respective providers?

t; and explain how they work in the Airflow docs - pointing helpfully to implementation sitting in providers. On Mon, Jan 30, 2023 at 6:32 PM Ferruzzi, Dennis wrote: > > Would this make it harder for a new user to find which executors are > available and get started? On one hand, for bet

Re: [DISCUSSION] Move K8S and Celery Executors (and related) to respective providers?

Would this make it harder for a new user to find which executors are available and get started? On one hand, for better or worse it makes the executor choice more of a conscious decision. On the other hand unless we're still setting one as the default and packaging it together - and you did

AIP-49 OpenTelemetry Support - Take Three

Third time’s the charm? Hi folks, looks like AIP-49 [1] hasn’t been touched in a while and I am interested in getting it implemented. If nobody has any objections, I’m going to start coming up with a plan to get this one done in the next little while. The last PoC for it was almost a year ago

Re: [DISCUSSION] Assessing what is a breaking change for Airflow (SemVer context)

> - We may not want to make a strong statement like "all executors are public". > It's just > impossible IMHO. > - Let's just mark a limited number of key methods/interfaces in each executor > as public, > and we ensure a strong backcompat for them. For any methods/interfaces not > marked, no

Re: [VOTE] AIP-52 Automatic setup and teardown tasks

+1 non-binding From: Ash Berlin-Taylor Sent: Monday, January 9, 2023 8:27 AM To: dev@airflow.apache.org Subject: [EXTERNAL] [VOTE] AIP-52 Automatic setup and teardown tasks CAUTION: This email originated from outside of the organization. Do not click links or

Re: [Discuss]whether fail early for Xcom.set when value exceeds the BLOB limit

Gah, sorry, I missed the other replies on this one. What they said. :P From: Ping Zhang Sent: Tuesday, December 20, 2022 10:43 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][Discuss]whether fail early for Xcom.set when value exceeds the BLOB limit

Re: [Discuss]whether fail early for Xcom.set when value exceeds the BLOB limit

100% fail early sounds like the right answer here. From: Ping Zhang Sent: Monday, December 19, 2022 7:02 PM To: dev@airflow.apache.org Subject: [EXTERNAL] [Discuss]whether fail early for Xcom.set when value exceeds the BLOB limit CAUTION: This email

Re: [PROPOSAL] Switching our CI runners to K8S controller open-sourced for Apache Arrow

Sounds like a new ASF project: K8S-CI-AAS? :P Joking aside, I'm all for consolidating effort if they have a solution that works for us and are willing to share the fruits of their labour. From: Jarek Potiuk Sent: Sunday, December 18, 2022 8:03 AM To:

Re: [DISCUSS] AIP-52 Automatic setup and tear down tasks

I love the idea. You've clearly put a lot of thought into this so maybe you've already considered and discarded these ideas, but I have two suggestions, for what they are worth. One improvement would be to automagically append/prepend them to the task list. If a task is tagged @setup, then

Re: [PROPOSAL] (Internal) move of provider packages to isolated "providers" sub-folders

> Somehow what you wanted to add here was lost so I am not sure what the > proposal is :). Gah, I knew I should have explained it as well. I was basically suggesting move the system tests for a given provider into that provider's tests module, alongside hooks, operators, sensors, etc:

Re: [PROPOSAL] (Internal) move of provider packages to isolated "providers" sub-folders

That was indeed a long one. I think I like where you are going with it and it feels like a nice step if the goal is to consider a full break. I also think consolidating everything related to a given provider in one place like that will make it much more intuitive for contributors. I have two

Re: [DISCUSSION] Assessing what is a breaking change for Airflow (SemVer context)

I think this sounds like a solid plan for moving forward. This whole discussion is kind of new to me so I've just been following along and learning, but the concept of defining what constitutes and Public API so we can iterate faster on "behind the scenes" stuff sounds like a solid plan. We

Re: [ANNOUNCE] New committer Andrey Anshin (Taragolis)

Well done, and much deserved. From: Jarek Potiuk Sent: Thursday, December 1, 2022 11:29 PM To: dev@airflow.apache.org Subject: [EXTERNAL] [ANNOUNCE] New committer Andrey Anshin (Taragolis) CAUTION: This email originated from outside of the organization. Do not

Re: [DISCUSS] Allow shorter voting periods for subsequent RCs

24 hours seems reasonable for follow ups to me. The argument I could see for keeping the 72 hours is that 72 hours means a decision would never be made over a weekend. That may not be a terrible idea to keep, but I'd say if the initial time is still 72 hours and revisions are only adding to

Re: Make KubernetesExecutor's multi_namespace_mode more flexible & enterprise-ready

On the surface this sounds like a solid improvement to me. I look forward to seeing the PR. From: Xiaodong Deng Sent: Friday, November 18, 2022 11:46 AM To: dev@airflow.apache.org Subject: [EXTERNAL] Make KubernetesExecutor's multi_namespace_mode more

Re: [Discussion] Airflow Newsletter name and branding

Manifold is fun. I am terrible at naming things, but also for your consideration: something along the lines of Smoke since smoke in a wind tunnel lets you see what's happening in the airflow? From: John Thomas Sent: Monday, November 14, 2022 11:00 AM To:

Re: Github Issue Triaging

d a PR for this. (following Elad example) https://github.com/apache/airflow/pull/27112 Best, Pierre Le mar. 18 oct. 2022 à 13:31, Kaxil Naik mailto:kaxiln...@gmail.com>> a écrit : Sure we will add you to the list On Mon, 17 Oct 2022 at 23:00, Ferruzzi, Dennis wrote: I'd actually

Re: Github Issue Triaging

I'd actually like to jump in on this as well, if possible. I tried to help with triage little in the past but without being able to add the tags myself, it felt silly just tagging someone else to add the tags. From: Elad Kalif Sent: Tuesday, October 11, 2022

Re: [VOTE] September 2022 PR of the Month

I'd second this one. https://github.com/apache/airflow/pull/23592 no more 'as dag' is really nice. From: Bas Harenslak Sent: Tuesday, September 27, 2022 11:11 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][VOTE] September 2022 PR of the Month CAUTION:

Re: [LAZY CONSENSUS] enable string normalization on black

+1 non-binding From: Felix Uellendall Sent: Wednesday, September 21, 2022 10:35 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][LAZY CONSENSUS] enable string normalization on black CAUTION: This email originated from outside of the organization. Do not

Re: [DISCUSS] string normalization in black

+1 non-binding to starting the lazy consensus? :P From: Daniel Standish Sent: Wednesday, September 21, 2022 9:55 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][DISCUSS] string normalization in black CAUTION: This email originated from outside of the

Re: [DISCUSS] string normalization in black

I'll weigh in on this most important of decisions. I find myself wishing I had time to standardize string quotes when I am in files and not doing it because I don't want to complicate PRs with unnecessary/unrelated changes. So I'd be for this. I prefer single-quotes myself, but I'd

Re: Add To Dev List

Just have them emailusers-subscr...@airflow.apache.org to subscribe. (from https://airflow.apache.org/community/) [https://airflow.apache.org/images/feature-image.png] Community | Apache

Re: User Kinceo1 posting spam review approvals

I do love it when a problem solves itself.. From: Tzu-ping Chung Sent: Friday, August 19, 2022 8:28 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL]User Kinceo1 posting spam review approvals CAUTION: This email originated from outside of the organization.

Re: [VOTE] AIP-44 - Airflow Internal API

I know this is past the deadline, but I wanted to wait to see the conversation play out to make a more informed call. I'd vote a (non-binding) +1. From: Abhishek Bhakat Sent: Thursday, August 11, 2022 2:06 AM To: dev@airflow.apache.org Subject: RE:

Re: [DISCUSS] Move "contrib" and all old classes to a separate package

> add dynamic attributes to __init__ of airflow.contrib, airflow.operators, > airflow.hooks. (to resolve to provider operators). This sounds promising to me. From: Jarek Potiuk Sent: Thursday, August 4, 2022 6:52 AM To: dev@airflow.apache.org Subject: RE:

Re: Auto-registering of DAGs in DAG file? (no `as dag` needed?)

I definitely like it, I love reducing boilerplate code like that. From: Ash Berlin-Taylor Sent: Tuesday, August 2, 2022 3:43 AM To: dev@airflow.apache.org Subject: [EXTERNAL] Auto-registering of DAGs in DAG file? (no `as dag` needed?) CAUTION: This email

Re: [VOTE] July 2022 PR of the Month

Limiting it to a non-committer PR in the future seems to be a good idea to me. It could act like a "Newcomer Spotlight" or something like that. From: Jarek Potiuk Sent: Friday, July 22, 2022 12:08 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][VOTE]

Re: [PROPOSAL] Simplification of www asset compilation for Breeze/dev env

I do like the sound of this. :thumbs-up: From: Jarek Potiuk Sent: Tuesday, July 19, 2022 3:00 PM To: dev@airflow.apache.org Subject: [EXTERNAL] [PROPOSAL] Simplification of www asset compilation for Breeze/dev env CAUTION: This email originated from outside

Re: [DISCUSS] - Grouping of concerns

I agree that the casual/personal user is a very important group, though I'm not sure if they really are the largest. I'd need to see what you are getting at before I agree that we should be segmenting our packaging. For example, if you are proposing spinning off Airflow Home Edition and

Re: [PROPOSAL] Remove "Label when reviewed" workflow

Yeah, I'd agree that it is just noise. From: Daniel Standish Sent: Saturday, June 25, 2022 10:25 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][PROPOSAL] Remove "Label when reviewed" workflow CAUTION: This email originated from outside of the

Re: task_id declarations

Yeah, alright, I guess that makes sense. Thank you both for the replies. Maybe it's just confirmation bias in action, but it seems like I almost always see DAGs written like ``` with DAG(dag_id="simple", start_date=datetime(2022, 4, 1)) as dag: task1 = Operator1(task_id='task1')

task_id declarations

Hi folks, I'm hoping for a little history lesson. I'm idly wondering if there is a way to make a fairly big change (for me), but want to understand the reason it is the way it is now, before I go and put much time into "fixing" it. Every time I write a DAG it bugs me that we have to

Re: Implicit DAG registration

I don't know what it would take under the hood, but I'm intrigued. From a user perspective, anything to make the DAG DRYer is a win IMHO. From: Malthe Sent: Wednesday, April 27, 2022 1:49 AM To: dev@airflow.apache.org Subject: [EXTERNAL] Implicit DAG

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

I still think that easy inclusion with a defined pruning process is best, but it's looking like that is the minority opinion. In which case, IFF we are going to be keeping them separate then I definitely agree that there needs to be a fast/easy/convenient way to find them.

Re: Code ownership over the provider's source code

I like your definition of "stewardship" in this case and I think it's in line with what I had in mind. From: Jarek Potiuk Sent: Monday, April 11, 2022 11:34 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] Code ownership over the provider's source code

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

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 think I'd just +1 Elad's comments. I don't know if we (the community) really need to be gatekeeping which providers get first class status like that. In the end, the users of any given provider become responsible for maintaining it, so I feel it sorts itself out without added bureaucracy.

Re: [PROPOSAL] New operator for "watcher" scenario

I like the concept, but don't have strong opinions on implementation. One thought would be that a similar operator may be handy if we're making that change. "run task ONLY IF an upstream task failed" might compliment your proposed "run task EVEN IF an upstream task failed". For example,

Re: [DISCUSS] how to name classes with abbreviations?

To expand on that thought, I find it easier to parse in cases like SQLAlchemy vs SqlAlchemy. It helps to visually indicate where that acronym stops and the next word starts. From: Ferruzzi, Dennis Sent: Friday, February 4, 2022 11:20 AM To: dev

Re: [DISCUSS] how to name classes with abbreviations?

In December Elad organized a community project (https://github.com/apache/airflow/issues/20139) which included un-PEP-8-ing the Amazon provider package, the all-caps acronyms you see there are/should all be deprecated. That said, I do find it easier to read as `BranchSqlOperator`, so that

Re: [PROPOSAL] MyPy incremental reintroduction

Sounds reasonable. Like you said, it shouldn't take long (relatively) to get the PRs that are already in the pipe cleared, so this wouldn't be required for long. From: Kaxil Naik Sent: Friday, January 21, 2022 5:27 AM To: dev@airflow.apache.org Subject: RE:

Re: OOM issue in the CI

Nice sleuthing. Dennis Ferruzzi SDE | Amazon MWAA [signature_1728047709] From: Jarek Potiuk Reply-To: "dev@airflow.apache.org" Date: Wednesday, November 10, 2021 at 10:14 AM To: Khalid Mammadov Cc: "dev@airflow.apache.org" Subject: RE: [EXTERNAL] OOM issue in the CI