Hello everyone, TL;DR; I wanted to propose one clarification to our release process for providers. I've been discussing it with Elad and few other people - Google team for example - and it seems that we should have some clarity on when and how we "break" our more-or-less release schedule for provider and allow to release a single ad-hoc provider because of some serious problem discovered after the previous version was released.
Currently we do not have a "process" or agreement when and how it could be done even though we have done this quite a few times in the past. We would like it to be really exceptional case - releasing providers - even if automated is a quite some overhead for release manager, and the PMC members (and contributors involved with testing) so grouping it in roughly bi-weekly batches works well and two weeks in most cases is not too long to wait for a fix (unless the issue is really critical and widespread). So I wanted to formalize it a bit - in a generic way that anyone could request such an ad-hoc provider release, but (and here is the catch) this means that the one who requests it takes a big part of the burden from the release manager and does it for him/her. In our release process only ONE thing needs to be done by a PMC member / release manager - signing and pushing the packages to SVN. All the rest - preparing documentation/changelogs bumping the version of the provider, creating the "status" issue, opening a vote and following it up - can be done by basically anyone (you don't have to be a committer). The timing is good for that - after some recent changes by Amogh, even the part of the release manager job that requires some "past knowledge" - preparing and reviewing changelog - is way simpler. Very recently Amogh improved `breeze release-management` command for it to be very nicely wizard-like driven - basically after you do `breeze release-management prepare-provider-documentation google` - for example, you will be shown all the to-be-released PRs one-by-one, you will have to classify them (bug/feature/breaking/misc) and the PR will be fully generated for you (previously it required manually updating the changelog and it was a bit tedious). Generally speaking it's just following a well maintained script and asking the release manager to build and commit packages in the middle of it. We could update the process and instructions to describe this and we could run a test release or two like that to make sure this process works. Two notes: * This should only happen for very important/critical issues that affect potentially a lot of users * If the person/stakeholder who wants to get the release have not tested/announced the status of the previously released package RC (in the "status" issue) that could have detect the problem, I'd say that's a strong indication that it can wait for the next wave (i.e. you had a chance to test it last time). Testing and commenting on the previous wave is a good indication that it just "slipped through" not because the provider was not looked at when RC was there, but because it was just accidentally missed during testing. I imagine the process like that: a) (say) John (made up name) sees a need to release ad-hoc release for a provider b) John prepares a documentation PR for this provider c) John pings #release-management channel explaining why there is a need for it d) Release manager either reject it (it's the RMs decision) or agrees (and in the second case merges PR, builds the package and pushes it to SVN/PyPI e) John continues with release process f) after voting is done Release Manager pushes packages to "downloads.apache.org" and PyPi g) John continues with all the remaining steps (announcement, closing issue etc.) That would be a very little overhead for the release manager, and the driving force and the burden for such an ad-hoc release (including following up with testing in the "status" issue) will remain with the one who wants the release out. WDYT? J. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org
