Re: [DISCUSS] New provider Common.time

+1 for moving core operators to providers. I also agree with Hussein's statement that common should only include things that are used at least twice in other providers. For this specific case, would `airflow.providers.time` probably work? Best, Wei > On Aug 15, 2024, at 3:46 AM, Hussein Awala

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

Late to the game here, but my vote stays with a strong +1 Thanks & Regards, Amogh Desai On Sun, Aug 11, 2024 at 11:47 PM Jarek Potiuk wrote: > The vote for AIP-67 has passed. > > AIP-67 > > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components >

Re: [VOTE] Release Airflow 2.10.0 from 2.10.0rc1

+1 (non-binding) The image looks good to me. I performed the following testing: - Verified that running our example DAGs did not reveal any regressions. - Verified AIP-64 TaskInstance Try History. - Verified DatasetAlias to support dynamic Dataset Event Emission and Dataset Creation (

Re: The Airflow main branch is now Airflow 3

Awesome, thanks for summarising nicely! Thanks & Regards, Amogh Desai On Mon, Aug 12, 2024 at 5:55 AM Jarek Potiuk wrote: > Indeed exciting!. I already cherry-picked a few changes, following the > process. > > J. > > > On Fri, Aug 9, 2024 at 3:49 PM Kaxil Naik wrote: > > > 🎉 Exciting! > > > >

Re: [ANNOUNCE] New PMC member: Jens Schaffler

Many Congratulations, Jens! Very well deserved! Thanks & Regards, Amogh Desai On Tue, Aug 13, 2024 at 6:55 AM Neil wrote: > Congrats Jens!! > > On Mon, Aug 12, 2024 at 8:29 PM Pierre Jeambrun > wrote: > > > Congratulations Jens! > > > > Le lun. 12 août 2024 à 20:53, Ferruzzi, Dennis > > > >

Re: [DISCUSS] Airflow 2/3 providers versioning support

Nice points to ponder upon, Jarek. Both topics are essential for ensuring that users have a clear path forwars. > We currently guarantee that the minimum Airflow version supported by a provider is the release date of the next minor version, plus 12 months. You’re asking if this should be adjusted

Re: Need more people engaged in our CI / infrastructure

I was away for the last few days too, and couldn't pay much attention to my email and Github. I am looking forward to Hussein's ppt in the next dev call, so that I can help in some of these areas as well. I have a decent knowledge of our CI and tests. Thanks & Regards, Amogh Desai On Wed, Aug 1

Re: [DISCUSS] New provider Common.time

+1 for this idea. I like the idea of moving the core operators entirely out to the providers. When it comes to naming, I do not have a strong preference but if we are looking at some alternatives to "common", my suggestions would be to try something like: - "shared": this will make some sense as w

Re: [DISCUSS] Airflow 2/3 providers versioning support

Going forward with Airflow 3 I also think we should re-consider what we version/depend upon from providers. If we move all providers (and likley also utility functions!) out of airflow core then the thing that a given provider needs to depend upon is the shared library/provider versions and the

Re: [VOTE] Release Airflow 2.10.0 from 2.10.0rc1

+1 (binding) Checked reproducibility, signatures, checksums, licences. Used it with the helm chart with a few different configs.

Re: [VOTE] Release Airflow 2.10.0 from 2.10.0rc1

+1 binding On Thu, 15 Aug 2024 at 16:42, Jed Cunningham wrote: > +1 (binding) Checked reproducibility, signatures, checksums, licences. Used > it with the helm chart with a few different configs. >

Re: [VOTE] Release Airflow 2.10.0 from 2.10.0rc1

+1 (binding) On Thu, 15 Aug 2024 at 16:42, Jed Cunningham wrote: > +1 (binding) Checked reproducibility, signatures, checksums, licences. Used > it with the helm chart with a few different configs. >

Re: [DISCUSS] New provider Common.time

Personally, I like "common" but if we decide to look for alternative names, how about calling them "core providers"? Or does that feel like an oxymoron since we always make a distinction between 'core" and "provider"? I also like Amogh's suggestion of "foundation". - ferruzzi

[RESULT][VOTE] Release Airflow 2.10.0 from 2.10.0rc1

Hello, Apache Airflow 2.10.0 (based on RC1) has been accepted. 3 "+1" binding votes received: - Kaxil Naik - Jed Cunningham - Ephraim Anierobi 2 "+1" non-binding votes received: - Rahul Vats - Utkarsh Sharma Vote thread: https://lists.apache.org/thread/sho6wrdkmtx2vzh18zqxmtw3z897455j I'll co

Re: [RESULT][VOTE] Release Airflow 2.10.0 from 2.10.0rc1

I think we need to get this backport into 2.10 https://github.com/apache/airflow/pull/41469 > On 16 Aug 2024, at 03:14, Utkarsh Sharma > wrote: > > Hello, > > Apache Airflow 2.10.0 (based on RC1) has been accepted. > > 3 "+1" binding votes received: > - Kaxil Naik > - Jed Cunningham > - Eph

Re: [RESULT][VOTE] Release Airflow 2.10.0 from 2.10.0rc1

Looks like the PR is late. Is it ok if we include it in the next Airflow 2 release? On Thu, 15 Aug 2024 at 20:29, Tzu-ping Chung wrote: > I think we need to get this backport into 2.10 > > https://github.com/apache/airflow/pull/41469 > > > > On 16 Aug 2024, at 03:14, Utkarsh Sharma > > > wrote

Re: [VOTE] Release Airflow 2.10.0 from 2.10.0rc1

Upgrade my +1 to binding, was able to add: -reproducible checks -SVN checks -License checks -Signature checks -SHA513 checks Sent from Outlook for iOS From: Ephraim Anierobi Sent: Thursday, August 15, 2024 7:06:02 PM To: dev@airflow.apache.o

Re: [VOTE] Release Airflow 2.10.0 from 2.10.0rc1

+1 binding On Thursday, August 15, 2024, Scheffler Jens (XC-AS/EAE-ADA-T) wrote: > Upgrade my +1 to binding, was able to add: > -reproducible checks > -SVN checks > -License checks > -Signature checks > -SHA513 checks > > Sent from Outlook for iOS > ___

Re: [RESULT][VOTE] Release Airflow 2.10.0 from 2.10.0rc1

I think this needs to be in Airflow 2 before 3.0 is released so people actually receive the notification for the breaking change we’re going to make. Assuming this does not make it into 2.10, what is the best option to send out the deprecation? > On 16 Aug 2024, at 03:36, Ephraim Anierobi wro

Re: [RESULT][VOTE] Release Airflow 2.10.0 from 2.10.0rc1

We can have it in 2.10.1 or 2.11.0 if it can't be in a patch release. On Thu, 15 Aug 2024 at 21:07, Tzu-ping Chung wrote: > I think this needs to be in Airflow 2 before 3.0 is released so people > actually receive the notification for the breaking change we’re going to > make. > > Assuming this

Re: [RESULT][VOTE] Release Airflow 2.10.0 from 2.10.0rc1

Hello, Sorry, I missed Jens' email in my count earlier. Here's the updated result. Apache Airflow 2.10.0 (based on RC1) has been accepted. 4 "+1" binding votes received: - Kaxil Naik - Jed Cunningham - Ephraim Anierobi - Scheffler Jens 2 "+1" non-binding votes received: - Rahul Vats - Utkarsh

Re: [VOTE] OTEL Provider to Apache Airflow

Hi all, regarding the discussion and vote around Provider for Apache Airflow, I have updated the github issue: https://github.com/apache/airflow/issues/37628 with more information of why I am proposing to implement this provider, and in what way the users can use it to instrument their DAG's. Origi

Re: [RESULT][VOTE] Release Airflow 2.10.0 from 2.10.0rc1

Somewhat unorganised thoughts— - Not all people may upgrade to 2.10.1 to receive the deprecation warning so this can be problematic. - 2.11 is probably a version all people should upgrade to (or at least be strongly recommended to), so that is a better target. - The situation here is a bit diffe

Re: [DISCUSS] New provider Common.time

Yeah I would favour a single "core provider": `apache-airflow-providers-core-modules` or just `apache-airflow-providers-core` sounds more apt. Example: from airflow.providers.core.sensors.datetime import DateTimeSensor from airflow.providers.core.operators.python import PythonOperator from airflo

[ANNOUNCEMENT] Last minute workshop spots available

[image: Airflow Summit 2024] *Dear community, * Great news! The deadline to reserve your room at the venue has been extended to August 19th. We've also opened up additional spots for our workshops. Join us for three days of exclusive keynotes and sessions, where indu

Re: [RESULT][VOTE] Release Airflow 2.10.0 from 2.10.0rc1

Hi Utkarsh, I just found another UI glitch about XCom Display, I think there is a small judgement needed if this should block the release if not too late. Issue is documented as 41514. I wpuld rate it low to medium. Jens Sent from Outlook for iOS ___

[DISCUSS] allow_trigger_in_future setting: keep or chop?

This setting, which affects scheduler behavior in a few places, seems like the type of thing that should not be configurable. I would propose we either always allow or always don't allow. Does anyone remember why we made it configurable? I don't have a strong feeling re allow or don't, but I gue

[ANNOUNCE] Apache Airflow 2.10.0 Released

Dear Airflow community, I'm happy to announce that Airflow 2.10.0 was just released. Note: The documentation will be published later today. The released sources and packages can be downloaded via https://airflow.apache.org/docs/apache-airflow/stable/installation/installing-from-sources.html Oth

[Meeting Notes] Airflow 3.0 Dev call - 8 Aug 2024

Hey all, I have updated our meeting notes document to summarize the discussion from our dev call on 8th Aug. Link: https://cwiki.apache.org/confluence/x/8ApeEg#Airflow3Devcall:MeetingNotes-8August2024 To all those who attended, can you please double-check and add if I have missed anything? To a

Re: Airflow debugging story survey

That indeed is a good idea. I got a chance to skim through the initial draft, mostly looks good. I also left a comment suggesting that we finalise the draft and distribute it in person at the AF summit. Thanks & Regards, Amogh Desai On Thu, Aug 8, 2024 at 5:19 PM Kaxil Naik wrote: > One opti