+1 (non-binding)

On Thu, Jan 18, 2024, 22:51 Scheffler Jens (XC-AS/EAE-ADA-T)
<jens.scheff...@de.bosch.com.invalid> wrote:

> +1 binding as discussed - looking forward for this and THANKS!
>
> Sent from Outlook for iOS<https://aka.ms/o0ukef>
> ________________________________
> From: Tzu-ping Chung <t...@astronomer.io.INVALID>
> Sent: Thursday, January 18, 2024 9:07:42 AM
> To: dev@airflow.apache.org <dev@airflow.apache.org>
> Subject: [VOTE] Accept AIP-60 (Standard URI representation for Airflow
> Datasets)
>
> AIP page:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FAIRFLOW%2FAIP-60%2BStandard%2BURI%2Brepresentation%2Bfor%2BAirflow%2BDatasets&data=05%7C02%7CJens.Scheffler%40de.bosch.com%7Cfeb80ec5aa4b4fa99c7a08dc17fc9ae4%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638411620901637967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZJ3XtYmB5k5NsO%2Ft%2F05QSxH9CIrYEiP4td09LZZ8rcI%3D&reserved=0
> <
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-60+Standard+URI+representation+for+Airflow+Datasets
> >
> Discussion thread:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Frf6c80ljjkml0l15h2jys7k713q3os1d&data=05%7C02%7CJens.Scheffler%40de.bosch.com%7Cfeb80ec5aa4b4fa99c7a08dc17fc9ae4%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638411620901637967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QQqR1gaRDfC9udbGbMubPfkyt73jSUmB7uPU%2BukCE2s%3D&reserved=0
> <https://lists.apache.org/thread/rf6c80ljjkml0l15h2jys7k713q3os1d>
>
> Reaction on the proposal seems to mostly positive, with most comments
> around what documentation should be added, and the exact criteria the AIP
> should be considered “done”. I believe I have addressed most of them; most
> notably, additional sentences have been added to the What defines this AIP
> as "done"? section to require the best practice to be demonstrated by
> example DAGs and tutorials in the documentation.
>
> One comment I left unaddressed is about auto-generating documentation from
> providers. This is mostly because I’m not quite sure how it can be
> practical. We can generate a list of supported protocols (s3, gcs, file,
> etc.), but that is not particularly useful to users without the actual
> format the URI would use. In the current implementation, each URI handler
> is a simple Python function, and it is not viable to extract logic from it
> unless we adopt some kind of rule-based parser (like regex, and even that
> is too complex to automatically generate documentation from). I am open to
> suggestions on this, so feel free to give a -1 with an idea on this.
> Otherwise I would move the proposal forward without auto documentation
> generation.
>
> This vote will be kept open for more than 72 hours even if three +1s are
> reached, to gather potential ideas on the documentation thing mentioned
> above. I intend to start implementation (including the example DAGs) in the
> mean time.
>
> TP
>

Reply via email to