Re: [VOTE] AIP 61 - Hybrid Executors

+1 binding Good work on the proposal, Niko. The most important part of this vote for me is the scoping you have done. Great work on that! Thanks & Regards, Amogh Desai On Thu, Feb 1, 2024 at 12:12 PM Jarek Potiuk wrote: > +1 (binding) . I think we know the scope (more importantly we also

Re: [VOTE] AIP 61 - Hybrid Executors

+1 (binding) . I think we know the scope (more importantly we also know what's out of the scope) On Thu, Feb 1, 2024 at 6:45 AM Scheffler Jens (XC-AS/EAE-ADA-T) wrote: > +1 binding - looking forward to implementation! > > Sent from Outlook for iOS >

Re: [VOTE] AIP 61 - Hybrid Executors

+1 binding - looking forward to implementation! Sent from Outlook for iOS From: Oliveira, Niko Sent: Thursday, February 1, 2024 6:12:02 AM To: dev@airflow.apache.org Subject: [VOTE] AIP 61 - Hybrid Executors Hey folks, The AIP for

[VOTE] AIP 61 - Hybrid Executors

Hey folks, The AIP for Hybrid Executors has been out for a few weeks now. Some great feedback came in and some challenges to scope which I think have all been addressed, and the AIP document has been updated where applicable. At this point I'd like to call a vote, and if all goes well, begin

RE: [ANNOUNCE] Starting experimenting with "Require conversation resolution" setting

I'm with Jarek, feel like an adult and like to see which comments are "open" and which are "resolved". That give clarity for me when I review where something is ready to be merged and which is still in discussion. But I also do not see a real burden for people disliking it, other than 1-3

Re: [ANNOUNCE] Starting experimenting with "Require conversation resolution" setting

I really understand the concerns. I am also not 100% happy either with the way you have to unresolve things to see past comments, and how links to old resolved comments are difficult to solve. This is certainly a drawback I see, and yes - it's a true concern. And Ash - really my point was not to

Re: [ANNOUNCE] Starting experimenting with "Require conversation resolution" setting

The point Ash is making is also my point. I am actually faster in clicking resolve now, just to move the PR forward in my mind. That does not necessarily mean I did a good job at resolving :-). Bolke. On Wed, 31 Jan 2024 at 16:26, Elad Kalif wrote: > I agree with Ash. > > I think leaving

Re: [ANNOUNCE] Starting experimenting with "Require conversation resolution" setting

I agree with Ash. I think leaving threads open is a feature not a problem. I used it with referencing todos in new issues and I think it's easier when the thread is kept open. Personally if I have a review that is important to me to follow up on then I publish it as request changes not as

Re: [ANNOUNCE] Starting experimenting with "Require conversation resolution" setting

To be clearer about the reason I don't want this Often times someone will leave a comment, and I will reply along the lines of "yes, fixed in fixup commit x" and want them to see it if they look/come back, but I don't think it's worth blocking merge on waiting for them to

Re: [ANNOUNCE] Starting experimenting with "Require conversation resolution" setting

I'm a -1 on keeping this as I don't see it gives us any real benefit other than a rubber-stamp. Let's treat people as intelligent grown ups instead of children who need strict rules. On 31 January 2024 09:37:50 GMT, Pankaj Koti wrote: >+1 to keep this > >@Bolke de Bruin: I am just thinking

Re: [ANNOUNCE] Starting experimenting with "Require conversation resolution" setting

+1 to keep this @Bolke de Bruin: I am just thinking more on your point and wondering that if someone has the intent to hide the conversation, they can anyway mark it as resolved irrespective of this configuration, no?

Re: [ANNOUNCE] Starting experimenting with "Require conversation resolution" setting

So while I have not experienced real challenges with it except for a PR that was really old and the github ui was hiding the comments, I have also not experienced any benefits. Sometimes resolving comments might als *hide* the actual thread. That means I can resolve without resolving and push

Re: [VOTE] Airflow Providers prepared on January 30, 2024

+1 (non-binding) Tested required changes are in. Thank you so much Elad for the release efforts. Best regards, *Pankaj Koti* Senior Software Engineer (Airflow OSS Engineering team) Location: Pune, Maharashtra, India Timezone: Indian Standard Time (IST) Phone: +91 9730079985 On Wed, Jan 31,

Re: [VOTE] Airflow Providers prepared on January 30, 2024

+1 (non-binding) Regards, Rahul Vats 9953794332 On Wed, 31 Jan 2024 at 12:21, Pankaj Singh wrote: > +1 (non-binding) > > Ran some dags and it worked fine! > > On Wed, Jan 31, 2024 at 7:55 AM Wei Lee wrote: > > > +1 (non-binding) > > > > Tested my changes with our example DAG without