potiuk commented on code in PR #26759: URL: https://github.com/apache/airflow/pull/26759#discussion_r984686750
########## docs/apache-airflow/production-deployment.rst: ########## @@ -222,6 +222,29 @@ you can exchange the Google Cloud Platform identity to the Amazon Web Service id which effectively means access to Amazon Web Service platform. For more information, see: :ref:`howto/connection:aws:gcp-federation` + +Applying patches from ``main`` +============================== + +On occasion, a user may want to apply a patch from ``main`` which has not yet made it into a release. Assuming you want to apply a specific PR to one of the official airflow images, you can apply roughly as follows. It's also possible to apply a specific commit. + +.. code-block:: docker Review Comment: > just patching unreleased code that is useful here; you might want to do your own backporting Yeah. But "airflow.apache.org" should only be about the code that is released via "https://downloads.apache.org/"; - this is the only way ASF releases "end-user" software. We also release "Docker Images" and "PIP" packages as "convenience/compiled packages" but - also those https://www.apache.org/legal/release-policy.html#compiled-packages: > As a convenience to users that might not have the appropriate tools to build a compiled version of the source, binary/bytecode packages MAY be distributed alongside official Apache releases. In all such cases, the binary/bytecode package MUST have the same version number as the source release and MUST only add binary/bytecode files that are the result of compiling that version of the source code release and its dependencies. So technically speaking - I think we cannot - in the "end-user" documentation provide the user instruction how to patch using PR/main/commits that have not been released yet. This is a bit blurry of course. But I think - to be honest - having those instructions are STILL valuable for the "power users" who are part of the "development community" - but not "end-users". This is mostly to reflect ASF philosophy and legal requirements, not technical reasons. I am actually curious if my way of thinking is correct or not. I will ask a LEGAL JIRA issue about it (this is the way how we can get the ASF statement about this actually and we will stop having opinions - both of us - we can get either some legal ASF team opinion on that, or even authoritative answer. -- 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]
