Yeah, that does make sense. However, I was suggesting a screen recorded demo to allow folks get a hang of things rather than following the recording step by step. The rationale here would be to make people familiar with what needs to be done and "where".
Thanks & Regards, Amogh Desai On Mon, Jul 22, 2024 at 12:48 PM Jarek Potiuk <ja...@potiuk.com> wrote: > 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 > > > > > > > > > >
