Re: [VOTE] Airflow Providers prepared on July 02, 2024 (openlineage rc2)

+1 (non-binding) Best, Wei > On Jul 3, 2024, at 8:14 PM, Rahul Vats wrote: > > +1 (non-binding) > > Verified with our example DAGs. > > Regards, > Rahul Vats > 9953794332 > > > On Wed, 3 Jul 2024 at 14:30, Maciej Obuchowski > wrote: > >> +1 (non binding) >> >> Verified by running some e

Re: [DISCUSS] @remove provide_bucket_name and @unify_bucket_name_and_key?

Thanks Vincent Re provide_bucket_name So, you've described what it does, but have not really made an argument that we should keep it. There may be good arguments for keeping it. Indeed, if it were an obvious choice to remove, I would not have brought it to the list! But, the mere fact that it

Re: Broken details link in 1.10.8 release notes

On Wed, Jul 3, 2024 at 9:07 PM Jarek Potiuk wrote: > Here is the content of that JIRA ticket. > > > bharathpalaksha commented on pull request #6310: AIRFLOW-5621 > - Failure callback > is not triggered when marked Failed on UI > URL: https://gi

Re: Broken details link in 1.10.8 release notes

Here is the content of that JIRA ticket. bharathpalaksha commented on pull request #6310: AIRFLOW-5621 - Failure callback is not triggered when marked Failed on UI URL: https://github.com/apache/airflow/pull/6310 Make sure you have checked *al

Broken details link in 1.10.8 release notes

Hello, I'm working on a major upgrade of our Airflow installation, and I noticed there is a broken link on the 1.10.8 release notes which may potentially contain information that I need. https://airflow.apache.org/docs/apache-airflow/2.4.0/release_notes.html#airflow-1-10-8-2020-02-07 Failure ca

Re: [VOTE] Airflow Providers prepared on July 02, 2024 (openlineage rc2)

Yep, happy to!

Re: [VOTE] Airflow Providers prepared on July 02, 2024 (openlineage rc2)

However due to reproducibility (what a cool feature) - the binaries are not going to change when I rebuild it and sign locally, So I guess if I will **just** replace signatures, you could potentially change your vote to +1 without having to restart voting. WDYT Jed? On Wed, Jul 3, 2024 at 8:

Re: [VOTE] Airflow Providers prepared on July 02, 2024 (openlineage rc2)

H. Thanks Jed. My bad. I have done it on a new machine and my key was not setup properly apparently. On Wed, Jul 3, 2024 at 8:46 PM Jed Cunningham wrote: > -1 > > Checked reproducibility, checksums, licences. Those look good! > > There seems to be a problem with the signatures, however? I di

Re: [VOTE] Airflow Providers prepared on July 02, 2024 (openlineage rc2)

-1 Checked reproducibility, checksums, licences. Those look good! There seems to be a problem with the signatures, however? I did reimport from KEYS. Jarek, do you maybe have a local key you were experimenting with for the trusted publishing workflow or something? Checking apache_airflow_provid

Re: [DISCUSS] @remove provide_bucket_name and @unify_bucket_name_and_key?

Overall, I agree with Daniel that these decorators can be very confusing (as user and maintainers). - `unify_bucket_name_and_key`. I am +1 to remove it. To me it does not offer real value and is a just a "hack" to presumably make user life easier. I prefer having a clear API with separate param

Re: [DISCUSS] AIP-72 Task Execution Interface (aka Task SDK)

Hi all, I’ve made some small changes to this AIP and I’m now happy with the state of it. First, a general point: I’ve tried to not overly-specify too many of the details on this one — for instance how viewing in-progress log will be handled is a TBD, but we know the constraints and the final de

Re: [VOTE] Airflow Providers prepared on July 02, 2024 (openlineage rc2)

+1 (non-binding) Verified with our example DAGs. Regards, Rahul Vats 9953794332 On Wed, 3 Jul 2024 at 14:30, Maciej Obuchowski wrote: > +1 (non binding) > > Verified by running some example DAGs. > > wt., 2 lip 2024 o 18:16 Jarek Potiuk napisał(a): > > > Hey all, > > > > I have just cut the

Re: Re: [VOTE] Airflow Providers prepared on July 02, 2024 (openlineage rc2)

Looks like we are good/tested - we will need two more PMC members votes to verify the provenance and release it this evening. On Wed, Jul 3, 2024 at 1:44 PM Kacper Muda wrote: > +1 (non binding) > > Also verified by running some example DAGs on different environments. > > On 2024/07/03 08:59:57

RE: Re: [VOTE] Airflow Providers prepared on July 02, 2024 (openlineage rc2)

+1 (non binding) Also verified by running some example DAGs on different environments. On 2024/07/03 08:59:57 Maciej Obuchowski wrote: > +1 (non binding) > > Verified by running some example DAGs. > > wt., 2 lip 2024 o 18:16 Jarek Potiuk napisał(a): > > > Hey all, > > > > I have just cut the

Re: [VOTE] Airflow Providers prepared on July 02, 2024 (openlineage rc2)

+1 (non binding) Verified by running some example DAGs. wt., 2 lip 2024 o 18:16 Jarek Potiuk napisał(a): > Hey all, > > I have just cut the new wave Airflow Providers packages. > > This email is calling a vote on the release, > which will last for 24 hours - which means that it will end on Wed,

[LAZY CONSENSUS] Switching to trusted publishing workflow for PyPI

As discussed in https://lists.apache.org/thread/t9l91nd4196n9mwsthhnx3qckcj45sxo I am calling for a lazy consensus on using "Trusted Publishing" PyPI workflow. The consensus will be reached at Mon, 8th of July 2024, 10 am CEST unless someone objects J

Re: [PROPOSAL] Use Trusted Publishing workflow for Airflow releases to PyPI

+1 from my side as well, as mentioned before there's no clear downside to it. Good stuff czw., 27 cze 2024, 06:34 użytkownik Amogh Desai napisał: > Excellent proposal! I see no down-side to the proposal > > Good investigation on the higher level implementation part as well. > > Thanks & Regards,