potiuk commented on PR #27829: URL: https://github.com/apache/airflow/pull/27829#issuecomment-1400705889
> > Feel free to merge if you think it's GOOD and useful :). > > Been thinking about the useful side of it :) let @jedcunningham decide Comment here - for @jedcunningham as well. But I wonder what others involved in the process think: I personally think it is super-useful. It makes the process repeatable but also it is largely self documenting. It's far easier to reason about it than README docs. But it does have some potential traps. Cons: * it's a little magical. release manager will not have to know what's under-the hood and if there is a consistent problem, all might seem to work but the release might be "wrong" * when things do not work, the release manager might easily say "it does not work" and rather than fix the problem, defer it to whoever can modify breeze (and knows how it work - at least a bit) Pros: * One of the useful parts of it is that it is going to be continuously tested (vast majority of it ) , so that you are not surprised by it not working any more due to unrelated changes * With breeze's built-in dry-run functionality, it is actually self-explanatory and if it does not work it allows the release manager to follow the whole process manually. Even if it is a little magical, you can find out how it works by `--dry-run` and still try to fix it manually My personal view: I personally usually err on the side of automation for those kind of things (as you are probably all well aware of that). One of the "features" of the Breeze rewrite in Python was to make it a little less magical - so that generally everyone here might understand and fix things. The fact that @ephraimbuddy wrote it largely himself with a little of my help is kinda proof that it works. Maybe it took a bit long and maybe there were a few things that require a bit more knowledge of the "magic" under-the-hood (especially when it comes to CI integration), it was not that bad I think. I think there is a big benefit of automating - it makes it actually possible to speed up cadence of releases. This is what we also see wiht @eladkal releasing the providers in increased cadence now - I think it would not be possible if not the automation of the process. There are still things there that could be improved and automated more. And "Release early, release often" is the mantra that I will continuously repeat as the way how we can improve things. The "provider" release process (after Elad's few improvements/teething problems when he started doing it) allows to run it as often as we want by anyone. We can share the burden of relases among many people, because the mundane, easy to make mistake parts of the process will be automated and only the "interesting" part remains (reviewing the changes, cherry-picking them, communicating with people about testing etc. etc. I find those parts really important and interesting and there are things I would not even want to automate ( rather to make it assisted by automation). This change above I think automates what's not "interesting" thus potentially opening the release process for more participants. Those my 3 cents. -- 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]
