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. > > > >
