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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
