potiuk commented on code in PR #30359:
URL: https://github.com/apache/airflow/pull/30359#discussion_r1152447606
##########
README.md:
##########
@@ -473,6 +477,38 @@ of the contributors to perform the cherry-picks and
carry-on testing of the olde
The availability of stakeholder that can manage "service-oriented" maintenance
and agrees to such a
responsibility, will also drive our willingness to accept future, new
providers to become community managed.
+### Suspending releases for providers
+
+In case a provider is found to require old dependencies that are not
compatible with upcoming versions of
+the Apache Airflow or with newer dependencies required by other providers, the
provider's release
+process can be suspended.
+
+This means:
+
+* The provider's status is set to "suspended"
+* No new releases of the provider will be made until the problem with
dependencies is solved
+* Sources of the provider remain in the repository for now (in the future we
might add process to remove them)
+* No new changes will be accepted for the provider (other than the ones that
fix the dependencies)
+* The provider will be removed from the list of Apache Airflow extras in the
next minor/major release
+ (2.7.0, 2.8.0, 3.0.0 etc.)
+* Tests of the provider will not be run on our CI (in main branch)
+* Dependencies of the provider will not be installed in our main branch CI
image nor included in constraints
+* We can still decide to apply security fixes to released providers - by
adding fixes to the main branch
+ but cherry-picking, testing and releasing them in the patch-level branch of
the provider similar to the
+ mixed governance model described above.
+
+The suspension might be triggered by any committer, providing that:
+
+* The maintainers of dependencies of the provider are notified about the issue
and are given a reasonable
+ time to resolve it (at least 1 week)
Review Comment:
That was indeed my point (no big deal). I think (and I also generally did
not describe it) there are few types of response:
1) resolving it (cool - we do nothing)
2) response "we are working it, coming soon" in which case we may
* decide to wait if we trust things will get resolved
* or suspend it anyway (because we think it will take more time or
we don't trust the promise
3) no response at all
I think it is really case-by-case and in case of some combinations of those
responses/reputation of a dependency/complexity of the change we might decide
to wait way longer than 1 week or be absolutely sure that if we don't get
response in 1 week, fix will never happen.
For example I have a very strong feeling we will not hear back anything in a
week for https://forums.mysql.com/read.php?50,708413) - whereas we already got
some feedback here in yandex
https://github.com/yandex-cloud/python-sdk/issues/71 and we already know that
apache-beam change is already merged and waits for release
https://github.com/apache/airflow/pull/30067 and we know that google team
works on updating all libraries in
https://github.com/apache/airflow/pull/30067. All of those require a bit
different approach/timing. I am quite sure we won't susspend google provider
off even if the target for the fix is May. But we might decide to suspend mysql
1 week after notice (old mysql provider will work and it has nothing to do with
mysql support by airflow as metadata).
This is BTW a nice spectrum of projects/responses :) - all of them are
about protobuf version requirement.
That's why I put "at least 1 week". To leave it open-ended but to put some
bare minimum waiting time. Sometimes we might simply want to unblock things
fast.
--
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]
