+1 for making the policy more clear but as for the involvement in the release process I have some concerns. I am not against it but we need to keep in mind that only the PMC have binding votes so it's not just about the release process it's also about respecting PMCs time.
I think the root cause of the issue is not the release cadence but the fact that most people test the code only once RC wave is cut. Most of the problems that were discovered during the RC can be discovered earlier. Anyone can build the packages locally at any time using Breeze and test it. If stakeholders will do so, the release process will be easier and we will need less rounds of RCs. I encourage all stakeholders to establish an internal process of building the artifacts using breeze and making sure they work as expected. Jarek I'd also like to note that several of the steps you suggested can not be made by anyone - it requires at least committer privilege and some require more privileges. We have: handling/announcing CVEs, social media announcing, Slack announcing, reporting in Apache tool about release, merging doc site PR, closing testing issue. On Wed, Jul 10, 2024 at 9:51 PM Kacper Muda <mudakac...@gmail.com> wrote: > 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 > > > > > > > > >
