+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
