potiuk commented on PR #31830: URL: https://github.com/apache/airflow/pull/31830#issuecomment-1831110615
> When you say "task" do you mean add a new breeze command that generates a "todo" issue? Yes. task to run with breeze. should be easy to add (I can do it) - but we do not have to do it "now" it's more of the process and "who" is doing it I am concerned about. With things like that, you have to consider how much overhead it introduces to someone who is going to remove it , and who that "someone" will be. And even if we do not implement all the tooling that is needed "now" - we should know what is the goal and what is missing to get there. Adding TODO:s in this way is the first part of the process "how we mark it" but we should also at least decide on what happens with it - i.e., how we remove it. Otherwise it's like a data that you keep by a company but have no idea how to use it. Typical Big-data projects companies have. I think we need to really start with "how we envision the process of removing the TODOs". The problem with the current proposal is the "moment in time" when those deprecations are collected and explained. What you've proposed in this PR - this collection happens AFTER the documentation is updated, packages (RC1) are already preparead and signed and commited to SVN and release manager is about to send "VOTE" email. So the "breeze task" that you put it in is just bad idea - because at that moment release manager has already done their job and if all is well, the RCs will be accepted as the new release. Maybe you have not realized that and that's why you put it there :). My point is that - we need to design "when" in the whole process this information should be collected and how to surface it to people who can do "something" about it - before the new provider's release is actually done. IMHO. the process should look like: 1) RM prepares a new wave and prepares documentation PR (changelog/commits)- also decides that some of the providers are going to have breaking change 2) The PR is there, and is going to be iterated for a few days (usualy happens) when others are rushing with some "last minute" merges. I think HERE is the right moment to automatically generate an issue with information "we are releasing new breaking providers : A, B, C and for each provider we have a list of things to be fixed. During iteration we are likely regenerate the info to track progress of what's still left to do from deprecations. 3) RM merges the doc PR (after merging last fixes and regenerating the changelog/commits documentation including those last minutes changes. 4) Send information to VOTE on the providers <-- CURRENT implementation only We cannot really put the burden of fixes on the shoulders of RM - we need to give RM some tooling to be able to identify and engage (ideally semi-automatically rather than individuallly finding and pinging the people) those who should fix the deprecations. RM is really supposed to the "mechanics" of release, generally speaking except committing the changelog, and maybe cherry-picking commits (in case of Airflow) RM should not "implement" anything - RM can at most coordinate others implementing PRs (as a general rule). So IMHO we need to do something to a) generate b) track what's left between 2) and 3) and not as part of 4) as is currently. and seems that having a task to do that in breeze and adding it as part of [release process](https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDER_PACKAGES.md#prepare-documentation) -- 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]
