Late to the party here but +1 on clarifying the policy. I am very much with Elad and Jed here regarding the chaos it could lead to so it definitely shouldn't be entirely driven by a non-RM (which is not even possible).
One improvement I can think of is in the announcement we make when we are about to cut the "RC". We should make it a point (along with instructions) to ask stakeholders test out the "early drop" of providers using breeze with clear indications on how to and with the "impact", if they don't. The impacts are what Jarek mentioned earlier regarding, but not limited to them waiting for the next wave of providers. Also, I think it will be really beneficial to have a "video" recording (screen recording is good enough) of a RM running the whole process so that interested folks can take up that responsibility, if need be. Thanks & Regards, Amogh Desai On Mon, Jul 15, 2024 at 3:18 PM Eugen Kosteev <eu...@kosteev.com> wrote: > +1 to this > > On Mon, Jul 15, 2024 at 11:24 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > Ok. If there are no more comments - I will now do some more work on the > > release process (I am going to finally look at the "Trusted Publishing" > > change for PyPI, and i will review and update the processes and along the > > way will mark and double check if the release process steps can be made > by > > non-PMC members/Release manager and find a way to nicely tag them in the > > release process (I will do it also for other release processes - just tag > > them). Then I will propose some updates to add the "ad-hoc" process lead > by > > other people and once it's ready, we might have a test/dry run with it. > > > > J. > > > > On Thu, Jul 11, 2024 at 10:57 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > > Yes. I think we all agree this should be a truly exceptional case with > > > wide impact and one that has no easy workaround (an example of such > > > issues from the past were when we have not realized that an older > > > version of ads-sdk has been disabled and none of the previous > > > providers would work. Or when the current version of the provider > > > released causes huge data loss (in which case we should yank it as > > > well) or similar kinds of issues. I think when someone wants to do it, > > > they should be absolutely convinced that it will be accepted, so if we > > > get in the scenario where most of such requests are rejected, it will > > > mean there is a misunderstanding that should be clarified. > > > > > > Re: Elad - yeah some of that for sure require committer to "merge" > > > things (but the PRs can be opened by anyone) - also some of the > > > announcements need apache email "from", but I think there are just a > > > few "touch points" with PMC member/release manager. We will find out > > > when we actually describe it (and try it once or twice). But I am > > > quite sure we can do it well - also to Kacper's comment, engaging more > > > people in the release process is generally a good idea. > > > > > > And I am very much with Vikram as well - that it should not introduce > > > chaos, so we should do it carefully. I don't think we are trading > > > speed for reliability here, if we all agree that this is just > > > "standard procedure for really exceptional situations". For me this is > > > mostly something like a fire-drill on a ship. You should be prepared > > > and have a process for it and do a "test run" from time to time so > > > that when it actually happens you can do it calmly, following all > > > trained and known processes and do it methodically and calmly. So I'd > > > say it's quite the reverse to introducing chaos - it's an attempt to > > > introduce an order to exceptional things that we know are going to > > > (rarely) happen and be prepared for it. > > > > > > J, > > > > > > On Thu, Jul 11, 2024 at 7:39 AM Vikram Koka > > > <vik...@astronomer.io.invalid> wrote: > > > > > > > > +1 on clarifying the policy for sure. > > > > > > > > However, I have concerns around the rest of this from a reliability > > > > standpoint. > > > > Unless this is to be used only for critical situations and for > > selective > > > > providers only, this seems like a speed vs. reliability tradeoff. > > > > > > > > I am uncomfortable with this. > > > > > > > > On Wed, Jul 10, 2024 at 12:22 PM Jed Cunningham < > > > jedcunning...@apache.org> > > > > wrote: > > > > > > > > > I'm kinda of the same opinion as Elad here. +1 for clarifying the > > > policy, > > > > > but I have some concerns on the rest of it. > > > > > > > > > > If we really do restrict these to critical situations, these should > > be > > > rare > > > > > enough that we aren't burning out RMs. Opening this door to only > say > > > "no, > > > > > not critical enough" more often than not (assuming folks are eager > to > > > do > > > > > frequent releases), seems a bit weird to me. > > > > > > > > > > > > > -- > Eugene >
