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. > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org
