Makes sense. I will do the same then - will cut the release branch and wait to cherry-pick the fixes.
Regards, Anton On Tue, Jun 18, 2019 at 10:25 PM Ismaël Mejía <[email protected]> wrote: > 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 <[email protected]> > wrote: > > > > > > > > On Tue, Jun 18, 2019 at 6:00 PM Anton Kedin <[email protected]> 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 < > [email protected]> 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 <[email protected]> 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 >
