Re: [VOTE] Airflow Providers prepared on August 19, 2024

provider openlineage is excluded from this wave due to bugs discovered. please continue the vote excluding this provider On Mon, Aug 19, 2024 at 5:27 PM Vincent Beck wrote: > +1 non binding. All AWS system tests are running successfully against > apache-airflow-providers-amazon==8.28.0rc1. You c

Re: [DISCUSS] Airflow 2.11 as bridge release

+1 non binding Thanks, Utkarsh Sharma On Tue, Aug 20, 2024 at 10:58 AM Elad Kalif wrote: > + 1 > but I think we should clarify the mental model of the 2.11 release. > > I wouldn't say it will have no features. If there are no features then why > 2.11? it can just be 2.10.x > I rather, we agree

Re: [VOTE] New Provider for Core operators/sensor

+1 binding on essential/essentials, standard, builtin, primary, - 0 binding on core, shared, base -1 binding on common path On Tue, Aug 20, 2024 at 12:45 AM Ephraim Anierobi wrote: > +1 standard > +0 essential/essentials (makes it seem required) > > If it were available, I would have chosen t

Re: [DISCUSS] Airflow 2.11 as bridge release

+ 1 but I think we should clarify the mental model of the 2.11 release. I wouldn't say it will have no features. If there are no features then why 2.11? it can just be 2.10.x I rather, we agree that it will have features which are relevant for the migration (for example: introduce new settings tha

Re: [DISCUSS] Airflow 2.11 as bridge release

+1 non binding. -- Regards, Vishnu Chilukoori On Mon, Aug 19, 2024 at 6:40 PM Vikram Koka wrote: > +1 > > Vikram > > > On Mon, Aug 19, 2024 at 12:36 PM Mehta, Shubham > > wrote: > > > +1 > > > > Shubham > > > > On 2024-08-19, 11:22 AM, "Michał Modras" > L

Re: [DISCUSS] Airflow 2.11 as bridge release

+1 Vikram On Mon, Aug 19, 2024 at 12:36 PM Mehta, Shubham wrote: > +1 > > Shubham > > On 2024-08-19, 11:22 AM, "Michał Modras" LID> wrote: > > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unle

Re: [VOTE] New Provider for Core operators/sensor

+1 standard +0 essential/essentials (makes it seem required) If it were available, I would have chosen the "core-add-on" option. It gives the feeling that it's a provider that complements the core(apache-airflow-providers-core-add-on). - 1 under common On Mon, 19 Aug 2024 at 22:12, Elad Kalif w

Re: [VOTE] New Provider for Core operators/sensor

Hussein I believe the intent is that the provider comes as one unit with Airflow (it will be part of the pre-installed providers like: sqlite, http, ...) so in that spirit is essential. just to clarify PMC voting -1 is considered veto but the rule is applied to code change, I am not sure what it m

Re: [VOTE] New Provider for Core operators/sensor

1. I'd like to cast my votes as follows: -1: "builtin", "primary", "core", "base" - all confuse between Airflow's real core and the new provider. -1: "shared "- a "common" synonym, there's no point to rename it in this case. +0: "essential(s)" - it distinguishes the new provider from Airflow's c

Re: [VOTE] New Provider for Core operators/sensor

-1 on common (I explained why in the discuss thread) +1 standard +0 builtin -0 primary +1 core -0 base -1 shared (same as common) -1 on essential/s (by definition, essential is a thing that is absolutely necessary, which is not the case here, a lot of users use Airflow without the core operators/se

Re: [VOTE] New Provider for Core operators/sensor

Easy one first: -1 on common +1 on standard, but also +0.5 on core or essential too.

Re: [DISCUSS] Airflow 2.11 as bridge release

+1 Shubham On 2024-08-19, 11:22 AM, "Michał Modras" mailto:michalmod...@google.com.inva>LID> 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. AVERTISSEMENT: Ce

Re: [DISCUSS] Airflow 2.11 as bridge release

+1 On Mon, Aug 19, 2024 at 4:21 PM Wei Lee wrote: > +1 > > Best, > Wei > > > On Aug 19, 2024, at 9:59 PM, Pierre Jeambrun > wrote: > > > > +1 > > > > On Mon, Aug 19, 2024 at 3:29 PM Jed Cunningham > > > wrote: > > > >> +1 > >> > > > -

Re: [Discussion] Add a new TriggerRule: Never

> Example dags are one place we have historically put dags / tasks that go in docs but are not run as system tests. Is that not still the case? I think from the very beginning when I joined airflow - example dags were meant to be "runnable" - so when you include core example dags in airflow - you

Re: [Discussion] Add a new TriggerRule: Never

Example dags are one place we have historically put dags / tasks that go in docs but are not run as system tests. Is that not still the case? On Mon, Aug 19, 2024 at 9:01 AM Ferruzzi, Dennis wrote: > Another part I had not considered is that since it's part of the hot-loop, > then a user-define

Re: [Discussion] Add a new TriggerRule: Never

Another part I had not considered is that since it's part of the hot-loop, then a user-defined callable could very possibly bring the whole thing to a grinding stop, either intentionally or not. So yeah, I guess without massive work to somehow decouple that so the whole scheduler loop didn't fr

Re: [VOTE] New Provider for Core operators/sensor

+1 essentials (plural is better IMHO) (great suggestion Pavankumar!) -1 nested under common binding - ferruzzi From: Vishnu Chilukoori Sent: Monday, August 19, 2024 7:28 AM To: dev@airflow.apache.org Subject: RE: [EXT] [VOTE] New Provider for Core operators/

Re: [VOTE] New Provider for Core operators/sensor

+1 standard & core -- can't pick one! -1 under common On Mon, 19 Aug 2024 at 15:29, Vishnu Chilukoori wrote: > +1 essential or essentials > -1 under common > (non-binding) > > > -- > Regards, > Vishnu > > On Mon, Aug 19, 2024 at 7:12 AM Wei Lee wrote: > > > Same here. > > > > 1. +1 essential/es

Re: [VOTE] New Provider for Core operators/sensor

+1 essential or essentials -1 under common (non-binding) -- Regards, Vishnu On Mon, Aug 19, 2024 at 7:12 AM Wei Lee wrote: > Same here. > > 1. +1 essential/essentials > 2. -1 under common > > Best, > Wei > > > On Aug 19, 2024, at 9:54 PM, Bas Harenslak > wrote: > > > > +1 for essential (saves

Re: [VOTE] Airflow Providers prepared on August 19, 2024

+1 non binding. All AWS system tests are running successfully against apache-airflow-providers-amazon==8.28.0rc1. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/8def71479a8a4e943f8c39f07793c9fb2cf1fcc6_8.28.0rc1.html On 2024/08/19 11:06:07 Jarek Potiu

Re: [DISCUSS] Airflow 2.11 as bridge release

+1 Best, Wei > On Aug 19, 2024, at 9:59 PM, Pierre Jeambrun wrote: > > +1 > > On Mon, Aug 19, 2024 at 3:29 PM Jed Cunningham > wrote: > >> +1 >> - To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional

Re: [VOTE] New Provider for Core operators/sensor

Same here. 1. +1 essential/essentials 2. -1 under common Best, Wei > On Aug 19, 2024, at 9:54 PM, Bas Harenslak wrote: > > +1 for essential (saves one letter) > -1 under common (feels like that would lead to path convention confusion) > > Bas > >> On 19 Aug 2024, at 15:40, Vincent Beck wrot

Re: [DISCUSS] Airflow 2.11 as bridge release

+1 On Mon, Aug 19, 2024 at 3:29 PM Jed Cunningham wrote: > +1 >

Re: [VOTE] New Provider for Core operators/sensor

+1 for essential (saves one letter) -1 under common (feels like that would lead to path convention confusion) Bas > On 19 Aug 2024, at 15:40, Vincent Beck wrote: > > Same here, > > +1 essential/essentials > -1 under common > > Binding > > On 2024/08/19 13:38:38 Pavankumar Gopidesu wrote: >>

Re: [VOTE] New Provider for Core operators/sensor

Same here, +1 essential/essentials -1 under common Binding On 2024/08/19 13:38:38 Pavankumar Gopidesu wrote: > Yes, I agree with Jarek :) > > +1 essential or essentials > -1 under common > (non-binding) > > Regards, > Pavan > > On Mon, Aug 19, 2024 at 2:32 PM Jarek Potiuk wrote: > > > +1 es

Re: [VOTE] New Provider for Core operators/sensor

Yes, I agree with Jarek :) +1 essential or essentials -1 under common (non-binding) Regards, Pavan On Mon, Aug 19, 2024 at 2:32 PM Jarek Potiuk wrote: > +1 essential (or essentials) > -1 under common > > (binding) > > Sorry for a bit of modification here, but I think > `apache-airflow-provider

Re: [VOTE] New Provider for Core operators/sensor

+1 essential/essentials -1 under common Same as Jarek, no opinion on plurality On 19 August 2024 14:32:01 BST, Jarek Potiuk wrote: >+1 essential (or essentials) >-1 under common > >(binding) > >Sorry for a bit of modification here, but I think >`apache-airflow-providers-essentials` (with `s` at

Re: [VOTE] New Provider for Core operators/sensor

+1 essential (or essentials) -1 under common (binding) Sorry for a bit of modification here, but I think `apache-airflow-providers-essentials` (with `s` at the end) would be more appropriate - showing also that it's about various "essentials". But I am good with either. This is a nuance. J On

Re: [DISCUSS] Airflow 2.11 as bridge release

+1

[VOTE] New Provider for Core operators/sensor

Migrate all operators/sensors from core to dedicated provider. *Discussion thread* https://lists.apache.org/thread/2dmlqkcmyomm4q7rrovygs6bw655zx07 This vote concerns two key decisions. 1. Provider name selection, options are: - essential - standard - builtin - primary - core - base - shared 2.

Re: [DISCUSS] Airflow 2.11 as bridge release

+1. I think that explicit discussion + vote will make it very clear and transparent that no new features will make it to Airflow 2, It will also - as a community decision - make it very easy to say "no" to any new features that people would like to target for Airflow 2 and divert their energy to A

Re: [DISCUSS] Airflow 2.11 as bridge release

Once we have an explicit agreement (with a VOTE after this discussion), it would be added as part of the docs similar to Elad's PR: https://github.com/apache/airflow/pull/41457 On Mon, 19 Aug 2024 at 13:22, Kaxil Naik wrote: > Hi team, > > After a discussion on the dev call and with some of you

Re: [VOTE] AIP-80: Explicit Template Fields in Operator Arguments

Thanks TP & everyone for the discussion here: +1 binding On Mon, 19 Aug 2024 at 13:07, Jarek Potiuk wrote: > +1 (binding). Thanks for responding to the concerns of compatibility, I > think personally this is crucial to have good Airflow 3 adoption. > > On Mon, Aug 19, 2024 at 1:34 PM Tzu-ping Ch

[DISCUSS] Airflow 2.11 as bridge release

Hi team, After a discussion on the dev call and with some of you on various forums, I wanted to propose the following: 1. It would only have bug fixes & deprecation warnings as a BRIDGE release -- NO features 2. We would release it after December so Airflow 3.0 features & removals are

Re: [VOTE] AIP-80: Explicit Template Fields in Operator Arguments

+1 (binding). Thanks for responding to the concerns of compatibility, I think personally this is crucial to have good Airflow 3 adoption. On Mon, Aug 19, 2024 at 1:34 PM Tzu-ping Chung wrote: > Hi all, > > I have modified the AIP document to reflect the conclusions we had during > the previous D

Re: [VOTE] AIP-80: Explicit Template Fields in Operator Arguments

Hi all, I have modified the AIP document to reflect the conclusions we had during the previous Dev call. Most significantly, the beginning of the Migration section has been rewritten to declare that Airflow 3 will continue to support the pre-AIP-80 templating syntax. Please take another look a

Re: [VOTE] Airflow Providers prepared on August 19, 2024

+1 (binding) - checked reproducibility, licences, checksums, signatures, checked all the changes of mine (mostly dependency upgrades). On Mon, Aug 19, 2024 at 10:18 AM Elad Kalif wrote: > Hey all, > > I have just cut the new wave Airflow Providers packages. This email is > calling a vote on the

Re: [DISCUSS] New provider Common.time

Since we are all aligned on the need to migrate all operators/sensors to dedicated providers and we are left only with the naming issue lets focus on that. Rom can you please open a vote thread for the naming of the provider? These are the options raised in the threads and we should vote on: *essen

[VOTE] Airflow Providers prepared on August 19, 2024

Hey all, I have just cut the new wave Airflow Providers packages. This email is calling a vote on the release, which will last for 72 hours - which means that it will end on August 22, 2024 08:15 AM UTC and until 3 binding +1 votes have been received. Consider this my (binding) +1. Note: packag