Cutting the next release branch is not equal to starting the release vote. In the past we have cut the branch even if there are still open issues and then give people some days to trim their issues.
So the release manager should create the release branch in the specified date and sync with the people working on the open issues so they cherry pick their PRs in the release branch if needed or move them to the next release and start the vote ONLY when the open issue list [1] count gets down to 0. Note: We can propose a different alternative but this has been effective in the past and gives contributors time to fix things to solve critical/blocker issues or issues that somehow need to be synced/discussed. Creating new RCs is ‘long’ and not yet 100% automated (so error-prone), also votes take long, so the less RCs/votes we have to do the better: [1] https://issues.apache.org/jira/browse/BEAM-7478?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.14.0 On Wed, Jun 19, 2019 at 3:19 AM Chamikara Jayalath <chamik...@google.com> wrote: > > > > On Tue, Jun 18, 2019 at 6:00 PM Anton Kedin <ke...@google.com> wrote: >> >> What is the right thing to do if it is not ready by the proposed branch cut >> time tomorrow? I don't think the Jira issue provides enough context about >> the severity of the problem and why it has to go out specifically in 2.14.0. >> Without additional context I think the expected path forward should look >> like this: >> * if it's a regression or something that really needs to block the release >> then I think more information about the problem is needed; > > > Context is that GCS may start throttling some of the requests and raising 429 > errors so Beam should implement logic for retrying such failures with > exponential backoff. Java SDK is already handling such failures correctly. > +Heejong Lee is actively working on a fix for Python SDK. I believe this will > be a relatively small change and a PR should be available within a day or so. > We can also try to cherry-pick the fix to release branch after it is cut if > you want to go ahead with the scheduled branch cut time. > > Thanks, > Cham > >> >> * if it's not a regression, proceed with the release even without the fix; >> * if the fix is ready before the release is completed, consider >> cherry-picking and re-doing the appropriate steps of the release process; >> * if the fix is not ready, consider doing a follow-up 2.14.1 release; >> * otherwise delay until 2.15.0; >> >> Regards, >> Anton >> >> >> On Tue, Jun 18, 2019 at 4:37 PM Chamikara Jayalath <chamik...@google.com> >> wrote: >>> >>> Please note that https://issues.apache.org/jira/browse/BEAM-7424 was marked >>> as a blocker and we'd like to get the fix to Python SDK into the 2.14 >>> release. >>> >>> Thanks, >>> Cham >>> >>> On Tue, Jun 18, 2019 at 4:16 PM Anton Kedin <ke...@google.com> wrote: >>>> >>>> It's a reminder, I am planning to cut the release branch tomorrow, on >>>> Wednesday, June 19, at 11am PDT (Seattle local time, corresponds to >>>> [19:00@GMT+1] and [18:00@UTC]). Please make sure all the code you want in >>>> the release is submitted by that time, and that all blocking Jiras have >>>> the release version attached. >>>> >>>> Thank you, >>>> Anton >>>> >>>> [1] >>>> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com >>>> [2] >>>> https://issues.apache.org/jira/browse/BEAM-7478?jql=project%20%3D%20BEAM%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20fixVersion%20%3D%202.14.0
