Screen recording is problematic - it has the problem that you need to re-record it when something changes and it limits flexibility - we had very good experience so far with describing the steps in the docs and correcting any mistakes and adding clarification every time someone run it.
On Wed, Jul 17, 2024 at 10:56 AM Pankaj Koti <pankaj.k...@astronomer.io.invalid> wrote: > +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 > > > > > >
