potiuk commented on PR #59558:
URL: https://github.com/apache/airflow/pull/59558#issuecomment-3775220401

   > We discussed a potential donation from this provider with the [Anyscale 
team](https://www.anyscale.com/) last Friday, but they don’t have the capacity 
to take this on right now. Given that [PyTorch has recently adopted 
Ray](https://pytorch.org/blog/pytorch-foundation-welcomes-ray-to-deliver-a-unified-open-source-ai-compute-stack/),
 one possible next step could be reaching out to the PyTorch Foundation to see 
whether they are interested in supporting this workstream as well.
   
   Thanks @tatiana -> this is good idea, what I would propose is to follow up 
with the current "extensions" to the Google Provider, and maybe - as part of 
AIP-95 implementation we could start building the list of providers that people 
would like to see in Airflow, and generally ask if there are those who would 
like to lead introduction of those - in this case, that someone who would like 
to see a need for Ray provider, could take on the task on reaching out and 
finding whether PyTorch foundation would be interested in being a steward and 
make the initial effort to create such a provider.  
   
   I think we should gravitate towards the solution that we - as maintainers - 
should not do it, but people want to have it in Airflow should take the 
leadership on it - and we should empower and enable such people to build the 
"stewardship" around such provider. In this case - if @raphaelauv would like to 
see it, we should likely have a blueprint on how to approach it and what needs 
to be done as part of such "leadership". And anyone of course could be such 
leader - it does not have to be a PMC member, or even the actual steward - it 
could be someone who wil encourage and convince the stwards to spend some time 
on it and commit to maintenance.
   
   I think the spirit of AIP-95 is such that we should do a lot to make it easy 
to accept such providers, and do a lot to setup a framework around it, the 
actual part of a) creating the provider, b) building a stewardship around it 
should be led by those who want such providers to be part of Airlfow, and 
contribute a bit of their leadership and energy to make it happen. This would 
also make this whole process much more scalable and long-term maintainable.  
@vikramkoka @kaxil  - as those where part of this  -> would you agree that 
seems like a good way to frame it?
   
   @raphaelauv -> would you be willing to take it on and try  to be one of the 
first who try it (we also need to get some first attempts of "finding out" how 
to do it to learn what is needed, so I guess more maintainer's help will be 
needed here and I am happy to support anyone who will take on such a task. Also 
I would see @VladaZakharova and her team to be participating there in finding 
good ways how to do proper coupling with such a provider when it's going to 
appear - and possibly @tatiana and her team could help by sharing their 
learning (or even code) with whoever who will agree to be the steward - at 
least initially. 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to