> 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 <[email protected]> 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 < > [email protected]> > 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 <[email protected]> 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 <[email protected]> > 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 < > > [email protected] > > > > > > > > wrote: > > > > > > > > > Easy one first: -1 on common > > > > > > > > > > +1 on standard, but also +0.5 on core or essential too. > > > > > > > > > > > > > > >
