+1 on clarifying the policy. +1 to Amogh's idea for checking the possibility of a screen recording/video of the steps. If it it'd doable, I definitely would like to be one the John(s) Jarek is mentioning to test out the possibility of helping the RM.
Best regards, *Pankaj Koti* Senior Software Engineer (Airflow OSS Engineering team) Location: Pune, Maharashtra, India Timezone: Indian Standard Time (IST) On Wed, Jul 17, 2024 at 12:42 PM Amogh Desai <amoghdesai....@gmail.com> wrote: > 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 > > >
