Re: [Discuss] Idea to increase RC voting participation

Hi all, Following back up on this thread, some tips on validating RCs are now documented [1]. Please do add any instructions, especially for more SDK/Runner specific combos. I'll take a closer look now into the automation discussed above on this thread. Thanks, Svetak [1]

Re: [Discuss] Idea to increase RC voting participation

> One easy and standard way to make it more resilient would be to make it idempotent instead of counting on uptime or receiving any particular event. Yep, agreed that this wouldn't be super hard if someone wants to take it on. Basically it would just be updating the tool to run on a schedule and

Re: [Discuss] Idea to increase RC voting participation

Agree. As long as we are getting enough of them, then our records as well as any automation depending on it are fine. One easy and standard way to make it more resilient would be to make it idempotent instead of counting on uptime or receiving any particular event. Kenn On Tue, Oct 24, 2023 at

Re: [Discuss] Idea to increase RC voting participation

Looks like for some reason the workflow didn't trigger. This is running on GitHub's hosted runners, so my best guess is an outage. Looking at a more refined query, this year there have been 14 issues that were missed by the automation (3 had their milestone manually removed) -

Re: [Discuss] Idea to increase RC voting participation

Just grabbing one at random for an example, https://github.com/apache/beam/issues/28635 seems like it was closed as completed but not tagged. I'm happy to see that the bot reads the version from the repo to find the appropriate milestone, rather than using the nearest open one. Just recording

Re: [Discuss] Idea to increase RC voting participation

On Tue, Oct 24, 2023 at 10:35 AM Kenneth Knowles wrote: > Tangentially related: > > Long ago, attaching an issue to a release was a mandatory step as part of > closing. Now I think it is not. Is it automatically happening? It looks > like we have 820 with no milestone >

Re: [Discuss] Idea to increase RC voting participation

Tangentially related: Long ago, attaching an issue to a release was a mandatory step as part of closing. Now I think it is not. Is it automatically happening? It looks like we have 820 with no milestone https://github.com/apache/beam/issues?q=is%3Aissue+no%3Amilestone+is%3Aclosed Kenn On Tue,

Re: [Discuss] Idea to increase RC voting participation

+1 for going by the commits since this is what matters at the end of the day. Also, many issues may not get tagged correctly for a given release due to either the contributor not tagging the issue or due to commits for the issue spanning multiple Beam releases. For example, For all commits in a

Re: [Discuss] Idea to increase RC voting participation

I'd probably vote to include both the issue filer and the contributor. It is pretty equally straightforward - one way to do this would be using all issues related to that release's milestone and extracting the issue author and the issue closer. This does leave out the (unfortunately sizable) set

Re: [Discuss] Idea to increase RC voting participation

Yes that's a good point to include also those who created the issue. On Mon, Oct 23, 2023, 19:18 Robert Bradshaw via dev wrote: > On Mon, Oct 23, 2023 at 7:26 AM Danny McCormick via dev < > dev@beam.apache.org> wrote: > >> So to summarize, I think there's broad consensus (or at least lazy >>

Re: [Discuss] Idea to increase RC voting participation

On Mon, Oct 23, 2023 at 7:26 AM Danny McCormick via dev wrote: > So to summarize, I think there's broad consensus (or at least lazy > consensus) around the following: > > - (1) Updating our release email/guidelines to be more specific about what > we mean by release validation/how to be helpful

Re: [Discuss] Idea to increase RC voting participation

Thanks for summarizing. For (1), I will send out this Google doc around the time of the next release where we can crowdsource ways to test the RC. I think it'd be valuable to approach a guide like this to be

Re: [Discuss] Idea to increase RC voting participation

So to summarize, I think there's broad consensus (or at least lazy consensus) around the following: - (1) Updating our release email/guidelines to be more specific about what we mean by release validation/how to be helpful during this process. This includes both encouraging validation within each

Re: [Discuss] Idea to increase RC voting participation

+1. This is a great idea to try. @Danny McCormick FYI as our next release manager. On Wed, Oct 18, 2023 at 2:30 PM Johanna Öjeling via dev wrote: > When I have contributed to Apache Airflow, they have tagged all > contributors concerned in a GitHub issue when the RC is available and asked > us

Re: [Discuss] Idea to increase RC voting participation

On Thu, Oct 19, 2023 at 12:18 PM Kenneth Knowles wrote: > +1 to more helpful guide on "how to usefully participate in RC validation" > but also big +1 to Robert, Jack, Johanna. > > TL;DR the RC validation is an opportunity for downstream testing. > > Robert alluded to the origin of the

Re: [Discuss] Idea to increase RC voting participation

+1 to more helpful guide on "how to usefully participate in RC validation" but also big +1 to Robert, Jack, Johanna. TL;DR the RC validation is an opportunity for downstream testing. Robert alluded to the origin of the spreadsheet: I created it long ago to validate that the human language on our

Re: [Discuss] Idea to increase RC voting participation

+1 That's a great idea. They have incentive to make sure the issue was resolved for them, plus we get to ensure there were no other regressions. On Wed, Oct 18, 2023 at 11:30 AM Johanna Öjeling via dev < dev@beam.apache.org> wrote: > When I have contributed to Apache Airflow, they have tagged

Re: [Discuss] Idea to increase RC voting participation

When I have contributed to Apache Airflow, they have tagged all contributors concerned in a GitHub issue when the RC is available and asked us to validate it. Example: #29424 . I found that to be an effective way to notify contributors of the RC and

Re: [Discuss] Idea to increase RC voting participation

I'm +1 on helping explain what we mean by "validate the RC" since we're really just asking users to see if their existing use cases work along with our typical slate of tests. I don't know if offloading that work to our active validators is the right approach though, documentation/screen share of

Re: [Discuss] Idea to increase RC voting participation

Great effort. I'm also interested in streamlining releases -- so if there are alot of manual tests that could be automated, would be great to discover and then look to address. On Tue, Oct 17, 2023 at 8:47 AM Robert Bradshaw via dev wrote: > +1 > > I would also strongly suggest that people try

Re: [Discuss] Idea to increase RC voting participation

+1 I would also strongly suggest that people try out the release against their own codebases. This has the benefit of ensuring the release won't break your own code when they go out, and stress-tests the new code against real-world pipelines. (Ideally our own tests are all passing, and this

[Discuss] Idea to increase RC voting participation

Hi all, I’ve participated in RC testing for a few releases and have observed a bit of a knowledge gap in how releases can be tested. Given that Beam encourages contributors to vote on RC’s regardless of tenure, and that voting on an RC is a relatively low-effort, high leverage way to influence