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