As a non-committer, I am strongly in favor of this idea. Just the other day, I was wondering if there was any way I could help make the providers’ releases happen more frequently. Although this isn’t the case here, I believe it is a step in a good direction and will ultimately be a significant improvement for the community, with most of the responsibility falling on those who are interested in fixing the bug.
śr., 10 lip 2024 o 20:39 Michał Modras <michalmod...@google.com.invalid> napisał(a): > Huge +1 - I think this would be a super useful process, in these critical > situations taking the burden off the release managers, and empowering > parties that are actually pressured to act (say owners of the service the > provider has integrations with). It also means the fixes for the overlooked > issues are available to the whole user base earlier. > > Also +1 on more thorough testing of the RCs - perhaps that could be > automated with all the dashboards that we have now. > > > > On Wed, Jul 10, 2024 at 6:49 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > 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 > > > > >
