Thanks Anton.

On Wed, Jun 19, 2019 at 9:34 AM Anton Kedin <[email protected]> wrote:

> 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
>>
>

Reply via email to