> +0.5 for essential/s - it gives me a sense that it is mandatory The essential/core/whatever-we-call-this will be an Airflow dependency and installed any time you install Airflow so that's pretty accurate.
- ferruzzi ________________________________ From: Amogh Desai <amoghdesai....@gmail.com> Sent: Tuesday, August 20, 2024 10:05 PM To: dev@airflow.apache.org Subject: RE: [EXT] [VOTE] New Provider for Core operators/sensor 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 courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. 1. Provider name +1 for standard, core +0.5 for essential/s - it gives me a sense that it is mandatory -1 for common, shared, builtin, primary 2. -1 for placing under common Thanks & Regards, Amogh Desai On Wed, Aug 21, 2024 at 2:10 AM Pankaj Singh <ags.pankaj1...@gmail.com> wrote: > +1 core > The implementation of certain operators and sensors, such as > TriggerDagRunOperator, ExternalTaskSensor, relies on the core module in a > way, so it makes sense to have the apache-airflow-providers-core for them. > We may keep other operators such as python, bash here. > > +1 (common.time) > There are many -1 votes for this option, and the reasoning that "Common > should be used by at least two other providers" seems valid. However, I > believe it is reasonable to keep sensors and operators related to time in > the common.time module. This approach appears consistent with the common-io > module and other modules within common. > > + 0 (others) > > Thanks > Pankaj > > On Tue, Aug 20, 2024 at 5:24 PM Aritra Basu <aritrabasu1...@gmail.com> > wrote: > > > -1 on common as well, +1 to standard/essentials (non-binding) > > -- > > Regards, > > Aritra Basu > > > > On Tue, 20 Aug 2024, 5:03 pm Elad Kalif, <elad...@apache.org> wrote: > > > > > > IMHO this vote is about a code change > > > > > > Then we will consider PMCs -1 as veto which disqualifies the specific > > name. > > > Looks like standard is the leading option which got enough +1 and no > > > vetos but lets see how it proceeds till vote time is closed. > > > > > > On Tue, Aug 20, 2024 at 2:11 PM Hussein Awala <huss...@awala.fr> > wrote: > > > > > > > > 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. > > > > > > > > What about installing Airflow 3 by default without any provider > > (minimal > > > > version), and adding the current default providers to a new extra > basic > > > or > > > > something else? > > > > > > > > Even if we decide to install it by default as we do with SQLite and > > HTTP > > > > providers, that doesn't make it "essential", where we can use Airflow > > and > > > > create dags without importing from that provider, except if we move > > some > > > of > > > > our base classes to this provider, which I challenged in my previous > > > email. > > > > > > > > > just to clarify PMC voting -1 is considered veto but the rule is > > > applied > > > > to code change, I am not sure what it means for naming > > > > > > > > IMHO this vote is about a code change > > > > > > > > On Tue, Aug 20, 2024 at 7:33 AM Elad Kalif <elad...@apache.org> > wrote: > > > > > > > > > +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 < > > > > > ephraimanier...@gmail.com> > > > > > wrote: > > > > > > > > > > > +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 <elad...@apache.org> > > wrote: > > > > > > > > > > > > > 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 means for naming > > > > > > > https://www.apache.org/foundation/voting.html > > > > > > > > > > > > > > On Mon, Aug 19, 2024 at 11:15 PM Hussein Awala < > huss...@awala.fr > > > > > > > > wrote: > > > > > > > > > > > > > > > -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/sensors) > > > > > > > > > > > > > > > > > Jarek: how about "apache-airflow-provider-essentials" - > that > > > will > > > > > not > > > > > > > > limit it to only operators, we could add mixins, triggers, > > hooks > > > > > > > (BaseHook) > > > > > > > > and everything else that falls into "essentials" category. > > > > > > > > > > > > > > > > This might make "essentials" an appropriate name, and I've > > > thought > > > > > > about > > > > > > > > it, but since we can't easily move > > AbstractOperator/BaseOperator, > > > > > > > Trigger, > > > > > > > > and other models used as base classes to a provider due to > the > > > need > > > > > to > > > > > > > > manage migration scripts, is it a good idea to move some of > > these > > > > > > classes > > > > > > > > and make the provider mandatory? Unless you have a suggestion > > to > > > > make > > > > > > > > Alembic work with different sources (to also move the future > > > > > migration > > > > > > > > scripts related to the moved models) > > > > > > > > > > > > > > > > On Mon, Aug 19, 2024 at 9:51 PM Jed Cunningham < > > > > > > jedcunning...@apache.org > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Easy one first: -1 on common > > > > > > > > > > > > > > > > > > +1 on standard, but also +0.5 on core or essential too. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
