Re: [VOTE] Proposal for adding Telemetry via Scarf

+1 binding From: Jed Cunningham Sent: Thursday, May 9, 2024 7:59:03 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] Proposal for adding Telemetry via Scarf CAUTION: This email originated from outside of the organization. Do not

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

+1 binding Excited for this one! From: Aritra Basu Sent: Thursday, April 18, 2024 7:37:08 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-67 Multi-team deployment of Airflow components CAUTION: This email originated from

Re: [ANNOUNCE] New committer: Wei Lee

Congrats Wei! Well deserved :) From: Scheffler Jens (XC-AS/EAE-ADA-T) Sent: Monday, April 8, 2024 2:12:41 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [ANNOUNCE] New committer: Wei Lee CAUTION: This email originated from outside of

Re: [DISCUSS] DRAFT AIP-67 Multi-tenant deployment of Airflow components

s/current/ddl-rowsecurity.html Cheers, Gabe -- Gabe Schenz From: Oliveira, Niko Date: Thursday, March 28, 2024 at 12:38 PM To: dev@airflow.apache.org Subject: [EXTERNAL] Re: [DISCUSS] DRAFT AIP-67 Multi-tenant deployment of Airflow components This Message originated outside your organization.

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

+1I'd love to see this as well. In the past, stability and long queue times of PR builds have been very frustrating. I'm not 100% sure this is due to using self hosted runners, since 35 queue depth (to my mind) should be plenty. But something about that setup has never seemed quite right to me

Re: [DISCUSS] DRAFT AIP-67 Multi-tenant deployment of Airflow components

Hey folks, just some thoughts on the topics below: 1) I'm not too fussed about the naming. There has been many years of us branding this multitenancy (talks, townhalls, email chains, etc), so a lot of our users are already familiar with this name. I'm not sure we'll benefit much by changing

Re: [VOTE] AIP-64: Keep TaskInstance try history

+1 (binding) Glad this is finally getting some love! From: Ankit Chaurasia Sent: Tuesday, March 26, 2024 2:58:13 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-64: Keep TaskInstance try history CAUTION: This email originated

Re: [DISCUSS] Applying D105 rule for our codebase ("undocumented magic methods") ?

I'm -1 to enabling D105 I don't think it will lead to helpful documentation. I think for the rare cases it is required it can left up to the developer or caught in PR review. Cheers, Niko From: Vincent Beck Sent: Wednesday, March 20, 2024 5:51:43 AM To:

Re: [DISCUSS] Considering trying out uv for our CI workflows

Fantastic results! > It also means that if you've been using breeze and were sometimes afraid to > hit "y" to rebuild the image, being afraid that it will take 20 minutes or > so - not any more. It should be WAY faster now. I'm very excited about this speed up as well as our CI :)

Re: [DISCUSS] Considering trying out uv for our CI workflows

The Astral folks also seem very focused on it being a drop-in/compliant replacement for pip. So I think it's definitely worth dropping it in and seeing if we get the expected performance improvements. If tests still pass and user facing constraints and install instructions remain unchanged I

Re: [DISCUSS] Rename channels on slack

hannels after personas is the way to go. I also > think > > we can consolidate some of these. I think: > > > > #dev-support -> from #development > > #troubleshooting > > #best-practices > > #random > > #first-pr-support --> change to #contributing

Re: [DISCUSS] Rename channels on slack

I'm not too picky on the names, but I'm +5 to Jed's approach of just archiving the current development channel and starting fresh with a new channel for contribution. There no manner of rebranding that we can do to save #development now, with that many folks in it. I'll throw #contributors

[RESULT][VOTE] AIP-61: Hybrid Execution

Hey folks! The voting for AIP-61: Hybrid Execution (https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-61+Hybrid+Execution) was completed on February 06, 2024 PST, and I am happy announce the following voting result: *Binding (+8) Votes* Jens Scheffler Jarek Potiuk Amogh Desai Dennis

[VOTE] AIP 61 - Hybrid Executors

Hey folks, The AIP for Hybrid Executors has been out for a few weeks now. Some great feedback came in and some challenges to scope which I think have all been addressed, and the AIP document has been updated where applicable. At this point I'd like to call a vote, and if all goes well, begin

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

Yeah, I've found this to be pretty smooth as well. In most cases comments were already resolved and in lesser cases it was useful to see which conversations still needed addressing before merging. +1 from me! From: Ryan Hatter Sent: Tuesday, January 30, 2024

Re: [VOTE] Accept AIP-60 (Standard URI representation for Airflow Datasets)

+1 (binding) From: Wei Lee Sent: Sunday, January 21, 2024 5:24:54 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] Accept AIP-60 (Standard URI representation for Airflow Datasets) CAUTION: This email originated from outside of the

Re: AIP-61 - Hybrid Executors

a task runs on one executor on one attempt, but a different executor on a different attempt. It might be nice if users could set a `use_default_executor_on_retry` kind of parameter. On Mon, Jan 15, 2024 at 1:05 PM Oliveira, Niko wrote: > Hey folks! > > I'd like to announce a new propos

Re: [ANNOUNCE] New PMC member: Andrey Anshin (taragolis)

Congrats Andrey! From: Pankaj Singh Sent: Monday, January 15, 2024 11:11:01 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [ANNOUNCE] New PMC member: Andrey Anshin (taragolis) CAUTION: This email originated from outside of the

Re: [DISCUSSION] Enabling `pre-commit.ci` application for Airflow

Interesting how 50/50 this one has turned out to be! I'm personally in favour (+1). The less I have to worry about accidental typos, indentation, quoting, etc the better, I can focus on important changes. It will also unblock many PRs from contributors that are otherwise mergeable except for

Re: [Discuss] New Airflow Community Provider: Teradata

This is fantastic! I love to see the testing and dashboards being invested in from the beginning, never gets old :) It shows that you really took the time to read the past discussions and documentation we have. I won't be able to look at the code in detail until the new year, but so far this

Re: [ANNOUNCE] New committer: Utkarsh Sharma

Congrats! Very well deserved! From: Pankaj Koti Sent: Monday, December 4, 2023 11:28:41 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [ANNOUNCE] New committer: Utkarsh Sharma CAUTION: This email originated from outside of the

Re: [DISCUSS] Capturing Architectural decisions (ADRS?)

I love this idea! Another option, that I don't think we as a community are very good at, is putting the context of the change in the git commit message itself. Those messages are already tightly associated into git history and the code itself via blame without needing to introduce an new

Re: [PROPOSE] Airflow Monthly Town-Hall

Love this idea! Jumping on this thread to be able to receive the agenda Briana mentioned (but I think there's no harm in just including it here for anyone to read). Cheers, Niko From: Briana Okyere Sent: Wednesday, November 29, 2023 9:30:21 AM To:

Re: [DISCUSS] Suspend/Remove Apache Scoop provider

+1 From: Pierre Jeambrun Sent: Thursday, November 23, 2023 10:28:52 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [DISCUSS] Suspend/Remove Apache Scoop provider CAUTION: This email originated from outside of the organization. Do not

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

If no one comes forward willing to support the executor long term I'm +1 for removal. From: Vincent Beck Sent: Thursday, November 16, 2023 10:59:40 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [DISCUSS] Suspend (Remove?) Daskexecutor

Re: [ANNOUNCE] New committer: Jens Scheffler

Congrats Jens!! From: Briana Okyere Sent: Tuesday, November 7, 2023 1:00:35 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [ANNOUNCE] New committer: Jens Scheffler CAUTION: This email originated from outside of the organization. Do not

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

+1 (binding) looking forward to having more native LLM capabilities in Airflow! From: Aritra Basu Sent: Wednesday, October 25, 2023 12:10:00 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] Add providers for Pinecone, OpenAI &

Re: The "no_status" state

I really like this idea as well! One of the _the most common_ questions I get from people managing an Airflow env is "Why is my task stuck in state X". Anything we can do to make that more discoverable and user friendly, especially in the UI instead of (or in addition to) logs would be

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

+1 to this! I also have a docs section half written on the executor interface and how to extend it. But I've been very busy with a few other items that are completing soon. Cheers, Niko From: Pankaj Koti Sent: Friday, September 8, 2023 12:03:35 PM To:

Re: [DISCUSS] move from semver to a more "rolling" release cycle for core

I'd prefer we stick with semver. As discussed already, there is a little friction with each approach, and it's who that friction lands on that's important. If we moved to a more time based breaking change approach then it reduces our frustration but shifts it over to our users. Whereas right

Re: [DISCUSS] Preventing users from misusing _PIP_ADDITIONAL_REQUIREMENTS ?

I'd vote for a period of time with warnings (either in the logs and/or in the Airflow UI), as a deprecation warning of sorts. Followed by removing the feature later on, unless we find that the warnings are enough to lower the operational load this causes us, but I think that's unlikely.

Re: [VOTE] Drop MsSQL as supported backend

+1 (binding) From: Jed Cunningham Sent: Monday, August 28, 2023 9:32:43 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [VOTE] Drop MsSQL as supported backend CAUTION: This email originated from outside of the organization. Do not click links or open

Re: [VOTE] Airflow Providers prepared on August 11, 2023

+1 (non-binding) Checked my change as well as ran an AWS System test suite on the release candidate, all green: https://aws-mwaa.github.io/open-source/system-tests/version/b5a4d36383c4143f46e168b8b7a4ba2dc7c54076_8.5.1rc1.html Cheers, Niko From: Vincent Beck

Re: [VOTE] Airflow Providers prepared on July 29, 2023

Tested the RC1 against the Amazon system tests and the results can be viewed here: https://aws-mwaa.github.io/open-source/system-tests/version/ddcd30e7c7f5daeab5f74fb3224a4d5e33cec95d_8.4.0rc1.html I would still like to do some more testing around executors. P.S. I think the Celery issue

Re: [ANNOUNCE] New PMC member: Hussein Awala

Congrats Hussein! From: Beck, Vincent Sent: Monday, July 31, 2023 7:32:08 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] [ANNOUNCE] New PMC member: Hussein Awala CAUTION: This email originated from outside of the organization. Do not click links or open

Re: [VOTE] AIP-57 Refactor SLA Feature

Looking forward to this one! I think the new behaviours will be much better than we have now. +1 (binding) From: Utkarsh Sharma Sent: Thursday, July 20, 2023 11:45:57 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][VOTE] AIP-57 Refactor SLA Feature

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

As I've said before I believe not pre-installing celery and k8s executors should be the ultimate goal, so I totally agree with this, but we need to do it in a way that minimizes impact. It's hard to catch every angle possible with these sorts of things (i.e. Daniel's point of folks installing

Re: [DISCUSS] Contributing "core" options by providers configuration ?

I agree with Jed. I don't actually mind allowing contribution of any config/section but I think any conflicts discovered should fail very loudly. From: Jed Cunningham Sent: Friday, July 21, 2023 7:45:02 AM To: dev@airflow.apache.org Subject: RE:

Re: [VOTE] Make (soon coming) dask provider preinstalled

-1 (binding) I think the eventual goal is all 3rd party executors (excluding Local, Sequential, etc) are not pre-installed. I think it will take a while for us to get there with Celery and K8s but it's the right thing to shoot for and we should start with Dask.

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

I think in a perfect world we'd only have the completely vendor neutral executors pre-installed (Local, Sequential, Debug) and anything else would need to be specifically installed by admins/users. I think if we were starting from scratch this would make the most sense, but clearly Kubernetes

Re: [ANNOUNCE] New committers: Vincent Beck, Phani Kumar, Maciej Obuchowski

Congrats all! Very well deserved! From: Wei Lee Sent: Tuesday, June 27, 2023 11:29:10 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][ANNOUNCE] New committers: Vincent Beck, Phani Kumar, Maciej Obuchowski CAUTION: This email originated from outside of the

Re: [VOTE] AIP-56 Extensible user management

+1 (binding) From: Jarek Potiuk Sent: Monday, June 19, 2023 7:38:08 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][VOTE] AIP-56 Extensible user management CAUTION: This email originated from outside of the organization. Do not click links or open

Re: [VOTE] Release Airflow 2.6.2 from 2.6.2rc1

+1 (non-binding) checked files, licenses, signatures, checksums, installation, and a few example dags. Cheers, Niko From: Beck, Vincent Sent: Tuesday, June 13, 2023 12:32:39 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][VOTE] Release Airflow 2.6.2 from

Re: [ANNOUNCE] New committer: Pankaj Singh

Woo! Congrats Prankaj! From: Ankit Chaurasia Sent: Monday, June 12, 2023 3:12:42 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][ANNOUNCE] New committer: Pankaj Singh CAUTION: This email originated from outside of the organization. Do not click links or

Re: [ANNOUNCE] New committer Hussein Awala

Congrats Hussein! From: Sung Yun Sent: Tuesday, April 11, 2023 4:41:15 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 open

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

Chiming in on a few of the topics discussed so far: - Context managers: I found most of the context manager syntax proposals a little hard to understand, but some better than others. Ultimately if I put my DAG author hat on, I find this declaration the most straightforward, clear and it's easy

Re: [DISCUSS] AIP-55 Rule-based timetable with logical composition

I love this idea, it's definitely helpful! I think an interesting topic to discuss for this project would be some kind of UI based date/calendar picker to help users construct these logical compositions. Something like `days("D1", "D2", "THU-SAT", "4>", "L1")` is quite inscrutable. A UI

Re: Request for feedback on proposal for new OpenLineage provider in Airflow

I'd like to join as well! (oliveira...@gmail.com) From: Igor Kholopov Sent: Wednesday, March 22, 2023 4:01:40 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL]Request for feedback on proposal for new OpenLineage provider in Airflow CAUTION: This email

Re: [ANNOUNCE] New PMC member: Brent Bovenzi

Congrats Brent!! From: Jorrick Sleijster Sent: Wednesday, March 15, 2023 9:09:07 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][ANNOUNCE] New PMC member: Brent Bovenzi CAUTION: This email originated from outside of the organization. Do not click links or

Re: [ANNOUNCE] New PMC member: Pierre Jeambrun

Congrats Pierre, well deserved! From: Kaxil Naik Sent: Wednesday, March 15, 2023 2:47:31 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][ANNOUNCE] New PMC member: Pierre Jeambrun CAUTION: This email originated from outside of the organization. Do not click

Re: [VOTE] Airflow Providers prepared on March 07, 2023

+1 (non-binding). Checked files, install (using the newly updated pmc Dockerfile :D), license and checksum. From: Jarek Potiuk Sent: Tuesday, March 7, 2023 1:53:26 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][VOTE] Airflow Providers prepared on March

Re: [NOTICE] Upcoming global changes to default GitHub Actions behavior for outside collaborators

I agree this is completely untenable, at least for Airflow. I commented on the Jira ticket as well with more thoughts. Cheers, Niko From: Jarek Potiuk Sent: Monday, February 13, 2023 4:08:23 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][NOTICE]

Re: [VOTE] AIP-53 OpenLineage in Airflow

+1 (binding) Overall I think this will make future development and growth for OL in Airflow much easier which will hopefully lead to more adoption! From: Vikram Koka Sent: Monday, February 13, 2023 8:20:23 AM To: dev@airflow.apache.org Subject: RE:

Re: [VOTE] Airflow Providers prepared on February 08, 2023

+1 (non-binding). Installed the amazon provider rc and tested my tagged PR (and another while I was at it). Also checked svn file counts, installation, checksums and licenses From: Jarek Potiuk Sent: Thursday, February 9, 2023 12:31:20 PM To:

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

I would love to see this. I think it would legitimize the interface a bit more and also help to encourage folks to not abuse/leak it in the future. AIP-51 is close to completion, I'd say 80%. We've boiled off most of the easier items and what's left is a few tricky decouplings (I have a PR for

Re: [VOTE] Airflow Providers prepared on January 14, 2023

res, checksums, licences. all looks good. On Mon, Jan 16, 2023 at 7:42 PM Oliveira, Niko wrote: +1 binding Our system tests show the AWS provider package as stable, a couple known flakey tests but we have regular passes with green across the board (public dashboard coming very s

Re: [VOTE] Airflow Providers prepared on January 14, 2023

+1 binding Our system tests show the AWS provider package as stable, a couple known flakey tests but we have regular passes with green across the board (public dashboard coming very soon!) From: Pankaj Singh Sent: Monday, January 16, 2023 10:20:00 AM To:

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

+1 (binding) Cheers, Niko From: Kevin Yang Sent: Monday, January 9, 2023 1:46:00 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][VOTE] AIP-52 Automatic setup and teardown tasks CAUTION: This email originated from outside of the organization. Do not

Re: [VOTE] AIP-50 Trigger DAG UI Extension with Flexible User Form Concept

+1 binding I really like this one, happy to see it coming along nicely! Cheers, Niko From: Tomasz Urbaszek Sent: Friday, December 30, 2022 4:20 AM To: dev@airflow.apache.org Subject: RE: [EXTERNAL][VOTE] AIP-50 Trigger DAG UI Extension with Flexible User Form

Re: [VOTE] New Provider: Cloudera

This has yet to be published by Google and Amazon - I know they are progressing a lot on making the automation and publishing regular result of the System tests from main in the way that we can verify that all tests pass - all that is done outside of the community resources and maintenance

Re: [PROPOSAL] Dealing with public runner test failues (Integration tests restructuring)

Awesome to hear this! I was really battling this issue last week, very excited for these improvements, let me know if I can help. Cheers, Niko From: Jarek Potiuk Sent: Tuesday, December 6, 2022 5:54:07 AM To: dev@airflow.apache.org Subject: [EXTERNAL]

Re: Proposal to Remove Executor Coupling in Core Airlfow Code Base

, 2022 at 9:16 PM Oliveira, Niko wrote: Hey folks! As a follow-up, if you're interested in following along with this project or even taking some tasks, I've created a dashboard using Github's new Projects tool. You can see the backlog of tasks, who's assigned, the estimated size and pr

Re: Proposal to Remove Executor Coupling in Core Airlfow Code Base

will be added as they come up, but the general skeleton is there. Cheers, Niko From: Oliveira, Niko Sent: Monday, November 7, 2022 4:41:44 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL]Proposal to Remove Executor Coupling in Core Airlfow Code Base CAUTION

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

1) users "peace of mind" as top priority: clarity of what they can expect from Airflow, and avoiding surprises when upgrading 2) targeting minimal disruption to user's workflows (though we might never reach absolute 100%) 3) making it easy for contributors and maintainers to decide on

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

Congrats Andrey! From: Jarek Potiuk Sent: Thursday, December 1, 2022 11:29:14 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 click

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

Thanks for starting this discussion Jarek! I think it's very important for us to get on the same page as a community about this. I'd love to go with a more flexible/common sense approach for considering breaking changes, and in a perfect world I think this would be best. However, I also think

[RESULT][VOTE] AIP-51 Removing Executor Coupling from Core Airlfow

Hey folks! The voting for AIP-51 Removing Executor Coupling from Core Airlfow (https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-51+Removing+Executor+Coupling+from+Core+Airlfow) was completed on November 21, 2022, and I am happy announce the following voting result: *Binding (+6)

[VOTE] AIP-51 - Removing Executor Coupling from Core Airlfow

Hey folks! I would like to start a vote for "AIP-51 - Removing Executor Coupling from Core Airlfow". You can find the AIP here: https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-51+Removing+Executor+Coupling+from+Core+Airlfow Discussion threads:

Re: Proposal to Remove Executor Coupling in Core Airlfow Code Base

users who implemented their own executors (not a very popular one also because of those problems this AIP is aiming to solve, but still we have to account for that). I personally think if there are no objections, this one is ready to start voting on. J. On Tue, Nov 8, 2022 at 1:42 AM Oliveira, Ni

Re: Proposal to Remove Executor Coupling in Core Airlfow Code Base

! From: Oliveira, Niko Sent: Monday, October 24, 2022 2:28 PM To: dev@airflow.apache.org Subject: [EXTERNAL] Proposal to Remove Executor Coupling in Core Airlfow Code Base Hey all! Recently I have spent some time investigating the occurrences of hardcoded Executor logic within core

Re: [PROPOSAL] Clarifications of triage team role including strenghtening importance of active triaging

in the previous description we jumped straight to "labels" but I believe (and that might be a good point to discuss with the current triagers and committers) that labeling of priorities/etc. should be somewhat "last" point of the triaging. We rarely (if at all) look at those labels and IMHO there

Re: [PROPOSAL] Clarifications of triage team role including strenghtening importance of active triaging

Thanks Jarek for the extra context and additions to the Traiging rst! An update from my end as a new Triage member: For the past few weeks I have looked at every single notification from Airflow Github and it has been a very informative learning experience. 1. Beyond tagging and updating

Proposal to Remove Executor Coupling in Core Airlfow Code Base

Hey all! Recently I have spent some time investigating the occurrences of hardcoded Executor logic within core Airflow code and put together a mini-AIP of sorts on Github Discussions (it was nice to use GH markdown and automatic code snippets). I'm particularly interested to hear if folks

Re: Github Issue Triaging

ator hasn't replied Regards, Kaxil On Wed, 5 Oct 2022 at 17:32, Oliveira, Niko wrote: Hey Elad! Yupp, I read through that rst and I'm going to help triage incoming issues more frequently. Though I do think reviewing the backlog of issues every quarter or so can be a useful exercise as well

Re: Github Issue Triaging

everyone to assist us by simply commenting in issues. The act of close/set labels is not time consuming, the real problem is actually handling the issues. On Wed, Oct 5, 2022 at 6:15 PM Oliveira, Niko wrote: Hello folks, Yesterday I attended a session at ApacheCon about best practices

Github Issue Triaging

Hello folks, Yesterday I attended a session at ApacheCon about best practices for managing bug/issue backlogs for a project and it got me reflecting on the Airflow issue backlog. I'd like to get more involved in initial (and continuous) triage of Airflow issues on Github. I chatted with Jarek

Re: Vending AWS System Test Results Back to the Community

e access to the Amazon account managed by Airflow community. In the past, commiters was supported by other people whom they trust e.g. commiter asked for help from another co-worker from her company when he needed it. This means that there are no restrictions on Amazon employees using this account a

Vending AWS System Test Results Back to the Community

Hey folks, Those of us on the AWS Airflow team (myself, Dennis F, Vincent B, Seyed H) have been working on a few projects over the past few months: 1. Writing example dags/docs for all existing Operators in the AWS Airflow provider package (done) 2. Writing AWS specific logic in Airflow

Re: [PROPOSAL] Provider's mixed governance model - first step of provider separation

+1 I agree this is a logical next step towards possibly separating provider code from the Airflow code base (and it's useful even if we never do that). Cheers, Niko From: Kamil Breguła Sent: Monday, June 20, 2022 1:30 PM To: dev@airflow.apache.org Subject: RE:

Re: Testing structure of your provider code

> I hope we can - as part of system tests improvements - add it for other > providers too :) I plan to add the tests for AWS soon :) From: Jarek Potiuk Sent: Sunday, May 8, 2022 12:34 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL]Testing structure of

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

Re: New Commiter: Malthe Borch

Congrats Malthe, well deserved! From: Vikram Koka Sent: Monday, February 21, 2022 2:08 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] New Commiter: Malthe Borch CAUTION: This email originated from outside of the organization. Do not click links or open

Re: New committer: Josh Fell

Congrats Josh, well deserved! From: Vikram Koka Sent: Monday, February 21, 2022 2:07 PM To: dev@airflow.apache.org Subject: RE: [EXTERNAL] New committer: Josh Fell CAUTION: This email originated from outside of the organization. Do not click links or open

Re: [DISCUSSION] AIP-47 New design of Airflow System Tests

Hey folks, I think both these sticking points are really a trade-off of simplicity vs consistency/reliability. And to be clear I'm not arguing for things to be more complex just for the heck of it, I agree that simplicity is great! But just that there needs to be a balance and we can't get

Re: [DISCUSSION] AIP-47 New design of Airflow System Tests

Hey folks, Very excited about this AIP! I work on the AWS OSS Airflow team. Getting the AWS system tests running has been a pet-project of mine for the past little while. I come from a test automation background, so this is dear to my heart :) Currently I have a branch that contains the

Re: [DISCUSS] Shaping the future of executors for Airflow (slowly phasing out Celery ?)

> We could even likely think about adding more options of similar kind for GCP/AWS/Azure - using native capabilities of those platforms rather than using generic "Kubernetes" as remote execution. I can imagine using Fargate (AWS team could contribute it ), Cloud Run (Google team), Azure Container

Re: OOM issue in the CI

Hey all, Just to throw another data point in the ring, I've had a PR stuck in the same way as well. Several retries are all failing with the same OOM. I've also dug through the Github Actions history and found a few others. So it doesn't seem to