Re: [DISCUSS] Preventing users from misusing _PIP_ADDITIONAL_REQUIREMENTS ?

Yep. I am also for the idea described by Pierre. In short - setting the requirement automatically turn on a DEBUG mode with all possible DEBUG features turned on. On Thu, Aug 31, 2023 at 6:03 AM Amogh Desai wrote: > Going through the discussions above, I was leaning towards the idea of > removin

Re: [VOTE] Drop MsSQL as supported backend

+1 binding On Wed, Aug 30, 2023 at 10:01 PM Ryan Hatter wrote: > +1 non-binding > > On Mon, Aug 28, 2023 at 3:29 PM Aritra Basu > wrote: > > > +1 (non-binding) > > Based on reading the previous mails, looks like a good idea to drop along > > with the migration support > > > > -- > > Regards, >

Re: [VOTE] Drop MsSQL as supported backend

+1 non-binding On Mon, Aug 28, 2023 at 3:29 PM Aritra Basu wrote: > +1 (non-binding) > Based on reading the previous mails, looks like a good idea to drop along > with the migration support > > -- > Regards, > Aritra Basu > > On Mon, Aug 28, 2023, 11:33 PM Oliveira, Niko > > wrote: > > > +1 (bi

Re: [DISCUSS] move from semver to a more "rolling" release cycle for core

Very good discussions going on here. Semver has been a point of concern for us too in our internal product. Some ideas emerging out of this could help me there. Thanks, Jarek and Niko. There are two points I'd like to stress on to say why semver is that important: - Compatibility: Without versio

Re: [DISCUSS] Preventing users from misusing _PIP_ADDITIONAL_REQUIREMENTS ?

Going through the discussions above, I was leaning towards the idea of removing it completely initially but came across Pierre's idea after. I like that! Thanks & Regards, Amogh Desai On Wed, Aug 30, 2023 at 1:58 PM Jarek Potiuk wrote: > Whoa.. I am glad I started it... I see some really good i

Re: [RESULT][VOTE] PR of the Month for August Airflow Newsletter

+1 for special mention in newsletter. Fantastic idea Briana! > On Aug 30, 2023, at 3:59 PM, Briana Okyere > wrote: > > Hey All, > > Thanks for your engagement with our PR of the Month Vote for the > August Newsletter. > Lots of great PRs this month! > > The results are in at: > > + 7 to #30

Re: [DISCUSS] move from semver to a more "rolling" release cycle for core

> Now, one elephant in the room - the 5 year security patches thing Jarek brought up. I freely admit I haven't tracked this at all, so please correct me if I'm wrong. If that ends up panning out though, I think we will have to reassess our strategy with providers too. Just to answer the last point

Re: [DISCUSS] move from semver to a more "rolling" release cycle for core

Shubham touched on it a bit, but I want to bring providers into the fold a bit as well. I don't think there is enough focus on provider versions. Us maintainers of Airflow have greatly benefited from being able to have breaking provider changes, but I always get the impression the average user just

Re: [RESULT][VOTE] PR of the Month for August Airflow Newsletter

Cool :) On Wed, Aug 30, 2023 at 9:59 PM Briana Okyere wrote: > Hey All, > > Thanks for your engagement with our PR of the Month Vote for the > August Newsletter. > Lots of great PRs this month! > > The results are in at: > > + 7 to #30259 by @vandonr-amz: Add a cache to `Variable` and `Connectio

[RESULT][VOTE] PR of the Month for August Airflow Newsletter

Hey All, Thanks for your engagement with our PR of the Month Vote for the August Newsletter. Lots of great PRs this month! The results are in at: + 7 to #30259 by @vandonr-amz: Add a cache to `Variable` and `Connection` when called at dag parsing time. < https://github.com/apache/airflow/pull/30

Re: [DISCUSS] move from semver to a more "rolling" release cycle for core

Or we could even have a policy that... just globally, by default, new features in core (and yes this may be not well defined) are automatically beta for 2 minor releases (whether they are hidden behind experimental flag or not). Other followup thought... And I could be reaching a bit here... but.

Re: [DISCUSS] move from semver to a more "rolling" release cycle for core

* Very much agree on using "experimental" more. So far we used it mostly as things where maintainers were somehow split on "is it good or not" - but having "experimental" flag by "default" for new big feature for 2 minor releases or so would be pretty good approach * Also I agree 'backwards compati

Re: [DISCUSS] move from semver to a more "rolling" release cycle for core

I should say... the cost is not quite "hindering adoption of the feature"... because it doesn't really matter to the heath of the project if users are using every single feature. Where the rubber meets the road here is probably more accurately understood as, perhaps the frustration a user might ha

Re: [VOTE] Airflow Providers prepared on August 29, 2023

+1 (binding) I checked the signatures, the checksums, the licences and the source code. I checked my changes, and they all look good. On Wed, Aug 30, 2023 at 6:25 PM Amogh Desai wrote: > +1 non binding. > > > Thanks, > Amogh Desai > > On Wed, Aug 30, 2023, 21:25 Jarek Potiuk wrote: > > > +1 (bi

Re: [DISCUSS] move from semver to a more "rolling" release cycle for core

Yeah I agree completely with more liberal use of something like more liberal use of "experimental". There's also "beta". While these definitions can be squishy, I think that beta can mean we're generally committed to keeping this feature but want more feedback whereas "experimental" can mean well

Re: [DISCUSS] move from semver to a more "rolling" release cycle for core

I agree with Jarek and Niko regarding the importance of SemVer for Airflow and how it aids in maintaining user trust. However, I am not a fan of the strict application of SemVer, especially in how we consider a small change in default values as a breaking change. IMHO, an alternative solution for

Re: [VOTE] Airflow Providers prepared on August 29, 2023

+1 non binding. Thanks, Amogh Desai On Wed, Aug 30, 2023, 21:25 Jarek Potiuk wrote: > +1 (binding): checked licences, sources, checksums, signatures. Re-checked > my changes. All looks good. > > On Wed, Aug 30, 2023 at 3:14 PM Rahul Vats wrote: > > > +1 (non binding) > > > > On Wed, 30 Aug, 2

Re: [VOTE] Airflow Providers prepared on August 29, 2023

+1 (binding): checked licences, sources, checksums, signatures. Re-checked my changes. All looks good. On Wed, Aug 30, 2023 at 3:14 PM Rahul Vats wrote: > +1 (non binding) > > On Wed, 30 Aug, 2023, 18:39 Pankaj Singh, > wrote: > > > + 1 (non-binding) > > > > My changes look good. > > > > Thanks

Re: [DISCUSS] move from semver to a more "rolling" release cycle for core

Just to add to my points about responding to our user. This is - of course - anecdotal - but this is a transcript from today's Slack conversation I got with one of the users, and this is not the first conversation I had of this kind: It's only because of Strict Semver policies I can very plainly

Re: [VOTE] Airflow Providers prepared on August 29, 2023

+1 (non binding) On Wed, 30 Aug, 2023, 18:39 Pankaj Singh, wrote: > + 1 (non-binding) > > My changes look good. > > Thanks > Pankaj > > On Wed, Aug 30, 2023 at 8:25 AM Wei Lee wrote: > > > +1 non-binding > > > > Tested with #33716 , > #33467 > >

Re: [VOTE] Airflow Providers prepared on August 29, 2023

+ 1 (non-binding) My changes look good. Thanks Pankaj On Wed, Aug 30, 2023 at 8:25 AM Wei Lee wrote: > +1 non-binding > > Tested with #33716 , #33467 > , #33433 < > https://github.com/apache/airflow/pul

Re: [VOTE] August 2023 PR of the Month

I'd cautiously say we seem to have a close-tie :D . BTW. I was also considering #30259 as a very close contender - but seems that the work by @eumiro has i's own separate category :D On Wed, Aug 30, 2023 at 8:50 AM Pierre Jeambrun wrote: > Tough call, +1 for @eumiro work. > > On Wed 30 Aug 2023

Re: [DISCUSS] Preventing users from misusing _PIP_ADDITIONAL_REQUIREMENTS ?

Whoa.. I am glad I started it... I see some really good ideas here :). On Wed, Aug 30, 2023 at 9:20 AM Pierre Jeambrun wrote: > Maybe we can introduce a global “DEBUG” config option/env variable. This > could control some more verbose logging but most importantly only when this > is turned on, w

Re: [DISCUSS] Preventing users from misusing _PIP_ADDITIONAL_REQUIREMENTS ?

Maybe we can introduce a global “DEBUG” config option/env variable. This could control some more verbose logging but most importantly only when this is turned on, we could use the sequential executor, debug executor, _PIP_ADDITIONAL_REQUIREMENTS and any other “debug/development” purpose options. L