subject:"Re\: \[VOTE\] Release 2.21.0, release candidate #1"

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-26 Thread Kyle Weaver

Thanks Kenn. Which experimental feature are you referring to?

On Tue, May 26, 2020 at 10:00 AM Kenneth Knowles  wrote:

> https://issues.apache.org/jira/browse/BEAM-10015 is a correctness
> issue, basically an experimental feature (I hope marked as such) not really
> working at all. It probably has a fairly small audience for now. I will not
> -1 because of it but I will -0. If there is another RC this should be
> included. Reuven probably has a better idea of the overall impact of the
> bug.
>
> Kenn
>
> On Thu, May 21, 2020 at 6:05 PM Thomas Weise  wrote:
>
>> Please note https://github.com/apache/beam/pull/11777 - another bug we
>> found while trying to upgrade to 2.21
>>
>> Other than that things look good.
>>
>> On Thu, May 21, 2020 at 4:14 PM Ahmet Altay  wrote:
>>
>>> +1 (again, validated with new whl files.)
>>>
>>> What about https://issues.apache.org/jira/browse/BEAM-10015? Is this a
>>> blocker?
>>>
>>> +Kenneth Knowles  +Reuven Lax  --
>>> since you are both tagged on the JIRA.
>>>
>>> On Thu, May 21, 2020 at 4:09 PM Kyle Weaver  wrote:
>>>
 > We *really* need to automate the building and deploying of artifacts,
 rather than have so many manual steps...

 Agreed. Luckily building wheels is one of only a couple steps that
 aren't automated yet. Partially related:
 https://issues.apache.org/jira/browse/BEAM-9388.

 On Thu, May 21, 2020 at 6:55 PM Luke Cwik  wrote:

> The 2.22 release is also being worked on. Rather allow that release
> pick up anything that isn't critical.
>
> On Thu, May 21, 2020 at 3:51 PM Robert Bradshaw 
> wrote:
>
>> We *really* need to automate the building and deploying of artifacts,
>> rather than have so many manual steps...
>>
>> The new set of wheels look good now. Verified all the hashes and
>> signatures and source tarball contents as well. Ran a couple of test
>> pipelines.
>>
>> I noticed https://github.com/apache/beam/pull/11722 was just merged.
>> Are we OK excluding that? Other than that looks good.
>>
>> +1 (binding) pending the one question above.
>>
>> On Thu, May 21, 2020 at 10:49 AM Kyle Weaver 
>> wrote:
>>
>>> Nevermind, uploading the wheels to dist.apache.org is part
>>> of ./sign_hash_python_wheels.sh, which I forgot to run. Wheels should 
>>> be up
>>> to date now, PTAL.
>>>
>>> On Thu, May 21, 2020 at 1:27 PM Kyle Weaver 
>>> wrote:
>>>
 > -1, the wheel files seem to be built against the wrong commit.

 Thanks for catching that Robert. I had to rebuild the wheels after
 some cherry picks. I validated that the wheels in 
 gs://beam-wheels-staging
 are up to date. They then must not have overwritten the wheels on
 dist.apache.org properly, which I assume we expect the Travis
 build to do. I might have to copy over the new wheels myself.

 > Since the current RC has been -1ed maybe we can include BEAM-9887
 as
 > part of the next RC, no?

 At this point, there is no need to go to a full second RC. If there
 turn out to be blocking issues with RC #1 that necessitate RC #2, we 
 can
 consider including BEAM-9887 then.

 On Thu, May 21, 2020 at 3:41 AM Ismaël Mejía 
 wrote:

> Since the current RC has been -1ed maybe we can include BEAM-9887
> as
> part of the next RC, no?
> It is definitely not a blocker but a nice to have.
>
> On Thu, May 21, 2020 at 2:26 AM Robert Bradshaw <
> rober...@google.com> wrote:
> >
> > -1, the wheel files seem to be built against the wrong commit.
> E.g.
> >
> > unzip -p
> apache_beam-2.21.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> apache_beam/runners/worker/bundle_processor.py | head -n 40
> >
> > notice the missing "import bisect" (among other things) missing
> from
> https://github.com/apache/beam/blob/release-2.21.0/sdks/python/apache_beam/runners/worker/bundle_processor.py
> .
> >
> > (I do agree that BEAM-9887 isn't severe enough to hold up the
> release at this point.)
> >
> >
> > On Tue, May 19, 2020 at 8:48 PM rahul patwari <
> rahulpatwari8...@gmail.com> wrote:
> >>
> >> Hi Luke,
> >>
> >> The release is not severely broken without PR #11609.
> >> The PR ensures that, while building a Row with Logical Type,
> the input value provided is proper. If we take FixedBytes logical 
> type with
> length 10, for example, the proper input value will be a byte array of
> length 10. But, without this PR, for FixedBytes logical type, the Row 
> will
> be

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-26 Thread Kenneth Knowles

https://issues.apache.org/jira/browse/BEAM-10015 is a correctness
issue, basically an experimental feature (I hope marked as such) not really
working at all. It probably has a fairly small audience for now. I will not
-1 because of it but I will -0. If there is another RC this should be
included. Reuven probably has a better idea of the overall impact of the
bug.

Kenn

On Thu, May 21, 2020 at 6:05 PM Thomas Weise  wrote:

> Please note https://github.com/apache/beam/pull/11777 - another bug we
> found while trying to upgrade to 2.21
>
> Other than that things look good.
>
> On Thu, May 21, 2020 at 4:14 PM Ahmet Altay  wrote:
>
>> +1 (again, validated with new whl files.)
>>
>> What about https://issues.apache.org/jira/browse/BEAM-10015? Is this a
>> blocker?
>>
>> +Kenneth Knowles  +Reuven Lax  --
>> since you are both tagged on the JIRA.
>>
>> On Thu, May 21, 2020 at 4:09 PM Kyle Weaver  wrote:
>>
>>> > We *really* need to automate the building and deploying of artifacts,
>>> rather than have so many manual steps...
>>>
>>> Agreed. Luckily building wheels is one of only a couple steps that
>>> aren't automated yet. Partially related:
>>> https://issues.apache.org/jira/browse/BEAM-9388.
>>>
>>> On Thu, May 21, 2020 at 6:55 PM Luke Cwik  wrote:
>>>
 The 2.22 release is also being worked on. Rather allow that release
 pick up anything that isn't critical.

 On Thu, May 21, 2020 at 3:51 PM Robert Bradshaw 
 wrote:

> We *really* need to automate the building and deploying of artifacts,
> rather than have so many manual steps...
>
> The new set of wheels look good now. Verified all the hashes and
> signatures and source tarball contents as well. Ran a couple of test
> pipelines.
>
> I noticed https://github.com/apache/beam/pull/11722 was just merged.
> Are we OK excluding that? Other than that looks good.
>
> +1 (binding) pending the one question above.
>
> On Thu, May 21, 2020 at 10:49 AM Kyle Weaver 
> wrote:
>
>> Nevermind, uploading the wheels to dist.apache.org is part
>> of ./sign_hash_python_wheels.sh, which I forgot to run. Wheels should be 
>> up
>> to date now, PTAL.
>>
>> On Thu, May 21, 2020 at 1:27 PM Kyle Weaver 
>> wrote:
>>
>>> > -1, the wheel files seem to be built against the wrong commit.
>>>
>>> Thanks for catching that Robert. I had to rebuild the wheels after
>>> some cherry picks. I validated that the wheels in 
>>> gs://beam-wheels-staging
>>> are up to date. They then must not have overwritten the wheels on
>>> dist.apache.org properly, which I assume we expect the Travis build
>>> to do. I might have to copy over the new wheels myself.
>>>
>>> > Since the current RC has been -1ed maybe we can include BEAM-9887
>>> as
>>> > part of the next RC, no?
>>>
>>> At this point, there is no need to go to a full second RC. If there
>>> turn out to be blocking issues with RC #1 that necessitate RC #2, we can
>>> consider including BEAM-9887 then.
>>>
>>> On Thu, May 21, 2020 at 3:41 AM Ismaël Mejía 
>>> wrote:
>>>
 Since the current RC has been -1ed maybe we can include BEAM-9887 as
 part of the next RC, no?
 It is definitely not a blocker but a nice to have.

 On Thu, May 21, 2020 at 2:26 AM Robert Bradshaw <
 rober...@google.com> wrote:
 >
 > -1, the wheel files seem to be built against the wrong commit.
 E.g.
 >
 > unzip -p
 apache_beam-2.21.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
 apache_beam/runners/worker/bundle_processor.py | head -n 40
 >
 > notice the missing "import bisect" (among other things) missing
 from
 https://github.com/apache/beam/blob/release-2.21.0/sdks/python/apache_beam/runners/worker/bundle_processor.py
 .
 >
 > (I do agree that BEAM-9887 isn't severe enough to hold up the
 release at this point.)
 >
 >
 > On Tue, May 19, 2020 at 8:48 PM rahul patwari <
 rahulpatwari8...@gmail.com> wrote:
 >>
 >> Hi Luke,
 >>
 >> The release is not severely broken without PR #11609.
 >> The PR ensures that, while building a Row with Logical Type, the
 input value provided is proper. If we take FixedBytes logical type with
 length 10, for example, the proper input value will be a byte array of
 length 10. But, without this PR, for FixedBytes logical type, the Row 
 will
 be built with input value with length less than the expected length.
 >> But, as long as the input value provided is correct, there
 shouldn't be any problems.
 >> I will change the fix version as 2.22.0 for BEAM-9887.
 >>
 >> Regards,

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-21 Thread Thomas Weise

Please note https://github.com/apache/beam/pull/11777 - another bug we
found while trying to upgrade to 2.21

Other than that things look good.

On Thu, May 21, 2020 at 4:14 PM Ahmet Altay  wrote:

> +1 (again, validated with new whl files.)
>
> What about https://issues.apache.org/jira/browse/BEAM-10015? Is this a
> blocker?
>
> +Kenneth Knowles  +Reuven Lax  -- since
> you are both tagged on the JIRA.
>
> On Thu, May 21, 2020 at 4:09 PM Kyle Weaver  wrote:
>
>> > We *really* need to automate the building and deploying of artifacts,
>> rather than have so many manual steps...
>>
>> Agreed. Luckily building wheels is one of only a couple steps that aren't
>> automated yet. Partially related:
>> https://issues.apache.org/jira/browse/BEAM-9388.
>>
>> On Thu, May 21, 2020 at 6:55 PM Luke Cwik  wrote:
>>
>>> The 2.22 release is also being worked on. Rather allow that release pick
>>> up anything that isn't critical.
>>>
>>> On Thu, May 21, 2020 at 3:51 PM Robert Bradshaw 
>>> wrote:
>>>
 We *really* need to automate the building and deploying of artifacts,
 rather than have so many manual steps...

 The new set of wheels look good now. Verified all the hashes and
 signatures and source tarball contents as well. Ran a couple of test
 pipelines.

 I noticed https://github.com/apache/beam/pull/11722 was just merged.
 Are we OK excluding that? Other than that looks good.

 +1 (binding) pending the one question above.

 On Thu, May 21, 2020 at 10:49 AM Kyle Weaver 
 wrote:

> Nevermind, uploading the wheels to dist.apache.org is part
> of ./sign_hash_python_wheels.sh, which I forgot to run. Wheels should be 
> up
> to date now, PTAL.
>
> On Thu, May 21, 2020 at 1:27 PM Kyle Weaver 
> wrote:
>
>> > -1, the wheel files seem to be built against the wrong commit.
>>
>> Thanks for catching that Robert. I had to rebuild the wheels after
>> some cherry picks. I validated that the wheels in 
>> gs://beam-wheels-staging
>> are up to date. They then must not have overwritten the wheels on
>> dist.apache.org properly, which I assume we expect the Travis build
>> to do. I might have to copy over the new wheels myself.
>>
>> > Since the current RC has been -1ed maybe we can include BEAM-9887 as
>> > part of the next RC, no?
>>
>> At this point, there is no need to go to a full second RC. If there
>> turn out to be blocking issues with RC #1 that necessitate RC #2, we can
>> consider including BEAM-9887 then.
>>
>> On Thu, May 21, 2020 at 3:41 AM Ismaël Mejía 
>> wrote:
>>
>>> Since the current RC has been -1ed maybe we can include BEAM-9887 as
>>> part of the next RC, no?
>>> It is definitely not a blocker but a nice to have.
>>>
>>> On Thu, May 21, 2020 at 2:26 AM Robert Bradshaw 
>>> wrote:
>>> >
>>> > -1, the wheel files seem to be built against the wrong commit. E.g.
>>> >
>>> > unzip -p
>>> apache_beam-2.21.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
>>> apache_beam/runners/worker/bundle_processor.py | head -n 40
>>> >
>>> > notice the missing "import bisect" (among other things) missing
>>> from
>>> https://github.com/apache/beam/blob/release-2.21.0/sdks/python/apache_beam/runners/worker/bundle_processor.py
>>> .
>>> >
>>> > (I do agree that BEAM-9887 isn't severe enough to hold up the
>>> release at this point.)
>>> >
>>> >
>>> > On Tue, May 19, 2020 at 8:48 PM rahul patwari <
>>> rahulpatwari8...@gmail.com> wrote:
>>> >>
>>> >> Hi Luke,
>>> >>
>>> >> The release is not severely broken without PR #11609.
>>> >> The PR ensures that, while building a Row with Logical Type, the
>>> input value provided is proper. If we take FixedBytes logical type with
>>> length 10, for example, the proper input value will be a byte array of
>>> length 10. But, without this PR, for FixedBytes logical type, the Row 
>>> will
>>> be built with input value with length less than the expected length.
>>> >> But, as long as the input value provided is correct, there
>>> shouldn't be any problems.
>>> >> I will change the fix version as 2.22.0 for BEAM-9887.
>>> >>
>>> >> Regards,
>>> >> Rahul
>>> >>
>>> >> On Wed, May 20, 2020 at 8:51 AM Luke Cwik 
>>> wrote:
>>> >>>
>>> >>> Rahul, do you believe that the release is severely broken
>>> without PR/11609 enough to require another release candidate or would
>>> waiting till 2.22 (which is due to be cut tomorrow)?
>>> >>>
>>> >>> On Tue, May 19, 2020 at 8:13 PM rahul patwari <
>>> rahulpatwari8...@gmail.com> wrote:
>>> 
>>>  Hi,
>>> 
>>>  Can the PR: https://github.com/apache/beam/pull/11609 be
>>> cherry-picked for 2.21.0 release?

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-21 Thread Thomas Weise

On Thu, May 21, 2020 at 4:08 PM Robert Bradshaw  wrote:

> On Thu, May 21, 2020 at 3:55 PM Luke Cwik  wrote:
>
>> The 2.22 release is also being worked on. Rather allow that release pick
>> up anything that isn't critical.
>>
>
> +1. The question is whether this will result in broken installs (e.g. if
> we don't exclude Flink 1.10.1 and the user tries to use it with this
> release).
>

That's fine. The RC, which is based on Flink 1.10.0, will also work with a
Flink 1.10.1 cluster.

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-21 Thread Ahmet Altay

+1 (again, validated with new whl files.)

What about https://issues.apache.org/jira/browse/BEAM-10015? Is this a
blocker?

+Kenneth Knowles  +Reuven Lax  -- since
you are both tagged on the JIRA.

On Thu, May 21, 2020 at 4:09 PM Kyle Weaver  wrote:

> > We *really* need to automate the building and deploying of artifacts,
> rather than have so many manual steps...
>
> Agreed. Luckily building wheels is one of only a couple steps that aren't
> automated yet. Partially related:
> https://issues.apache.org/jira/browse/BEAM-9388.
>
> On Thu, May 21, 2020 at 6:55 PM Luke Cwik  wrote:
>
>> The 2.22 release is also being worked on. Rather allow that release pick
>> up anything that isn't critical.
>>
>> On Thu, May 21, 2020 at 3:51 PM Robert Bradshaw 
>> wrote:
>>
>>> We *really* need to automate the building and deploying of artifacts,
>>> rather than have so many manual steps...
>>>
>>> The new set of wheels look good now. Verified all the hashes and
>>> signatures and source tarball contents as well. Ran a couple of test
>>> pipelines.
>>>
>>> I noticed https://github.com/apache/beam/pull/11722 was just merged.
>>> Are we OK excluding that? Other than that looks good.
>>>
>>> +1 (binding) pending the one question above.
>>>
>>> On Thu, May 21, 2020 at 10:49 AM Kyle Weaver 
>>> wrote:
>>>
 Nevermind, uploading the wheels to dist.apache.org is part
 of ./sign_hash_python_wheels.sh, which I forgot to run. Wheels should be up
 to date now, PTAL.

 On Thu, May 21, 2020 at 1:27 PM Kyle Weaver 
 wrote:

> > -1, the wheel files seem to be built against the wrong commit.
>
> Thanks for catching that Robert. I had to rebuild the wheels after
> some cherry picks. I validated that the wheels in gs://beam-wheels-staging
> are up to date. They then must not have overwritten the wheels on
> dist.apache.org properly, which I assume we expect the Travis build
> to do. I might have to copy over the new wheels myself.
>
> > Since the current RC has been -1ed maybe we can include BEAM-9887 as
> > part of the next RC, no?
>
> At this point, there is no need to go to a full second RC. If there
> turn out to be blocking issues with RC #1 that necessitate RC #2, we can
> consider including BEAM-9887 then.
>
> On Thu, May 21, 2020 at 3:41 AM Ismaël Mejía 
> wrote:
>
>> Since the current RC has been -1ed maybe we can include BEAM-9887 as
>> part of the next RC, no?
>> It is definitely not a blocker but a nice to have.
>>
>> On Thu, May 21, 2020 at 2:26 AM Robert Bradshaw 
>> wrote:
>> >
>> > -1, the wheel files seem to be built against the wrong commit. E.g.
>> >
>> > unzip -p
>> apache_beam-2.21.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
>> apache_beam/runners/worker/bundle_processor.py | head -n 40
>> >
>> > notice the missing "import bisect" (among other things) missing
>> from
>> https://github.com/apache/beam/blob/release-2.21.0/sdks/python/apache_beam/runners/worker/bundle_processor.py
>> .
>> >
>> > (I do agree that BEAM-9887 isn't severe enough to hold up the
>> release at this point.)
>> >
>> >
>> > On Tue, May 19, 2020 at 8:48 PM rahul patwari <
>> rahulpatwari8...@gmail.com> wrote:
>> >>
>> >> Hi Luke,
>> >>
>> >> The release is not severely broken without PR #11609.
>> >> The PR ensures that, while building a Row with Logical Type, the
>> input value provided is proper. If we take FixedBytes logical type with
>> length 10, for example, the proper input value will be a byte array of
>> length 10. But, without this PR, for FixedBytes logical type, the Row 
>> will
>> be built with input value with length less than the expected length.
>> >> But, as long as the input value provided is correct, there
>> shouldn't be any problems.
>> >> I will change the fix version as 2.22.0 for BEAM-9887.
>> >>
>> >> Regards,
>> >> Rahul
>> >>
>> >> On Wed, May 20, 2020 at 8:51 AM Luke Cwik 
>> wrote:
>> >>>
>> >>> Rahul, do you believe that the release is severely broken without
>> PR/11609 enough to require another release candidate or would waiting 
>> till
>> 2.22 (which is due to be cut tomorrow)?
>> >>>
>> >>> On Tue, May 19, 2020 at 8:13 PM rahul patwari <
>> rahulpatwari8...@gmail.com> wrote:
>> 
>>  Hi,
>> 
>>  Can the PR: https://github.com/apache/beam/pull/11609 be
>> cherry-picked for 2.21.0 release?
>>  If not, the fix version has to be changed for BEAM-9887.
>> 
>>  Regards,
>>  Rahul
>> 
>>  On Wed, May 20, 2020 at 6:05 AM Ahmet Altay 
>> wrote:
>> >
>> > +1, I validated python 2 and 3 quickstarts.
>> >
>> > On Tue, May 19, 2020 at 4:57 PM

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-21 Thread Kyle Weaver

> We *really* need to automate the building and deploying of artifacts,
rather than have so many manual steps...

Agreed. Luckily building wheels is one of only a couple steps that aren't
automated yet. Partially related:
https://issues.apache.org/jira/browse/BEAM-9388.

On Thu, May 21, 2020 at 6:55 PM Luke Cwik  wrote:

> The 2.22 release is also being worked on. Rather allow that release pick
> up anything that isn't critical.
>
> On Thu, May 21, 2020 at 3:51 PM Robert Bradshaw 
> wrote:
>
>> We *really* need to automate the building and deploying of artifacts,
>> rather than have so many manual steps...
>>
>> The new set of wheels look good now. Verified all the hashes and
>> signatures and source tarball contents as well. Ran a couple of test
>> pipelines.
>>
>> I noticed https://github.com/apache/beam/pull/11722 was just merged. Are
>> we OK excluding that? Other than that looks good.
>>
>> +1 (binding) pending the one question above.
>>
>> On Thu, May 21, 2020 at 10:49 AM Kyle Weaver  wrote:
>>
>>> Nevermind, uploading the wheels to dist.apache.org is part
>>> of ./sign_hash_python_wheels.sh, which I forgot to run. Wheels should be up
>>> to date now, PTAL.
>>>
>>> On Thu, May 21, 2020 at 1:27 PM Kyle Weaver  wrote:
>>>
 > -1, the wheel files seem to be built against the wrong commit.

 Thanks for catching that Robert. I had to rebuild the wheels after some
 cherry picks. I validated that the wheels in gs://beam-wheels-staging are
 up to date. They then must not have overwritten the wheels on
 dist.apache.org properly, which I assume we expect the Travis build to
 do. I might have to copy over the new wheels myself.

 > Since the current RC has been -1ed maybe we can include BEAM-9887 as
 > part of the next RC, no?

 At this point, there is no need to go to a full second RC. If there
 turn out to be blocking issues with RC #1 that necessitate RC #2, we can
 consider including BEAM-9887 then.

 On Thu, May 21, 2020 at 3:41 AM Ismaël Mejía  wrote:

> Since the current RC has been -1ed maybe we can include BEAM-9887 as
> part of the next RC, no?
> It is definitely not a blocker but a nice to have.
>
> On Thu, May 21, 2020 at 2:26 AM Robert Bradshaw 
> wrote:
> >
> > -1, the wheel files seem to be built against the wrong commit. E.g.
> >
> > unzip -p
> apache_beam-2.21.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> apache_beam/runners/worker/bundle_processor.py | head -n 40
> >
> > notice the missing "import bisect" (among other things) missing from
> https://github.com/apache/beam/blob/release-2.21.0/sdks/python/apache_beam/runners/worker/bundle_processor.py
> .
> >
> > (I do agree that BEAM-9887 isn't severe enough to hold up the
> release at this point.)
> >
> >
> > On Tue, May 19, 2020 at 8:48 PM rahul patwari <
> rahulpatwari8...@gmail.com> wrote:
> >>
> >> Hi Luke,
> >>
> >> The release is not severely broken without PR #11609.
> >> The PR ensures that, while building a Row with Logical Type, the
> input value provided is proper. If we take FixedBytes logical type with
> length 10, for example, the proper input value will be a byte array of
> length 10. But, without this PR, for FixedBytes logical type, the Row will
> be built with input value with length less than the expected length.
> >> But, as long as the input value provided is correct, there
> shouldn't be any problems.
> >> I will change the fix version as 2.22.0 for BEAM-9887.
> >>
> >> Regards,
> >> Rahul
> >>
> >> On Wed, May 20, 2020 at 8:51 AM Luke Cwik  wrote:
> >>>
> >>> Rahul, do you believe that the release is severely broken without
> PR/11609 enough to require another release candidate or would waiting till
> 2.22 (which is due to be cut tomorrow)?
> >>>
> >>> On Tue, May 19, 2020 at 8:13 PM rahul patwari <
> rahulpatwari8...@gmail.com> wrote:
> 
>  Hi,
> 
>  Can the PR: https://github.com/apache/beam/pull/11609 be
> cherry-picked for 2.21.0 release?
>  If not, the fix version has to be changed for BEAM-9887.
> 
>  Regards,
>  Rahul
> 
>  On Wed, May 20, 2020 at 6:05 AM Ahmet Altay 
> wrote:
> >
> > +1, I validated python 2 and 3 quickstarts.
> >
> > On Tue, May 19, 2020 at 4:57 PM Hannah Jiang <
> hannahji...@google.com> wrote:
> >>
> >> I confirmed that licenses/notices/source code are added to Java
> and Python docker images as expected.
> >>
> >>
> >> On Tue, May 19, 2020 at 2:36 PM Kyle Weaver <
> kcwea...@google.com> wrote:
> >>>
> >>> Thanks for bringing that up Steve. I'll leave it to others to
> vote on whether that

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-21 Thread Robert Bradshaw

On Thu, May 21, 2020 at 3:55 PM Luke Cwik  wrote:

> The 2.22 release is also being worked on. Rather allow that release pick
> up anything that isn't critical.
>

+1. The question is whether this will result in broken installs (e.g. if we
don't exclude Flink 1.10.1 and the user tries to use it with this release).


> On Thu, May 21, 2020 at 3:51 PM Robert Bradshaw 
> wrote:
>
>> We *really* need to automate the building and deploying of artifacts,
>> rather than have so many manual steps...
>>
>> The new set of wheels look good now. Verified all the hashes and
>> signatures and source tarball contents as well. Ran a couple of test
>> pipelines.
>>
>> I noticed https://github.com/apache/beam/pull/11722 was just merged. Are
>> we OK excluding that? Other than that looks good.
>>
>> +1 (binding) pending the one question above.
>>
>> On Thu, May 21, 2020 at 10:49 AM Kyle Weaver  wrote:
>>
>>> Nevermind, uploading the wheels to dist.apache.org is part
>>> of ./sign_hash_python_wheels.sh, which I forgot to run. Wheels should be up
>>> to date now, PTAL.
>>>
>>> On Thu, May 21, 2020 at 1:27 PM Kyle Weaver  wrote:
>>>
 > -1, the wheel files seem to be built against the wrong commit.

 Thanks for catching that Robert. I had to rebuild the wheels after some
 cherry picks. I validated that the wheels in gs://beam-wheels-staging are
 up to date. They then must not have overwritten the wheels on
 dist.apache.org properly, which I assume we expect the Travis build to
 do. I might have to copy over the new wheels myself.

 > Since the current RC has been -1ed maybe we can include BEAM-9887 as
 > part of the next RC, no?

 At this point, there is no need to go to a full second RC. If there
 turn out to be blocking issues with RC #1 that necessitate RC #2, we can
 consider including BEAM-9887 then.

 On Thu, May 21, 2020 at 3:41 AM Ismaël Mejía  wrote:

> Since the current RC has been -1ed maybe we can include BEAM-9887 as
> part of the next RC, no?
> It is definitely not a blocker but a nice to have.
>
> On Thu, May 21, 2020 at 2:26 AM Robert Bradshaw 
> wrote:
> >
> > -1, the wheel files seem to be built against the wrong commit. E.g.
> >
> > unzip -p
> apache_beam-2.21.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> apache_beam/runners/worker/bundle_processor.py | head -n 40
> >
> > notice the missing "import bisect" (among other things) missing from
> https://github.com/apache/beam/blob/release-2.21.0/sdks/python/apache_beam/runners/worker/bundle_processor.py
> .
> >
> > (I do agree that BEAM-9887 isn't severe enough to hold up the
> release at this point.)
> >
> >
> > On Tue, May 19, 2020 at 8:48 PM rahul patwari <
> rahulpatwari8...@gmail.com> wrote:
> >>
> >> Hi Luke,
> >>
> >> The release is not severely broken without PR #11609.
> >> The PR ensures that, while building a Row with Logical Type, the
> input value provided is proper. If we take FixedBytes logical type with
> length 10, for example, the proper input value will be a byte array of
> length 10. But, without this PR, for FixedBytes logical type, the Row will
> be built with input value with length less than the expected length.
> >> But, as long as the input value provided is correct, there
> shouldn't be any problems.
> >> I will change the fix version as 2.22.0 for BEAM-9887.
> >>
> >> Regards,
> >> Rahul
> >>
> >> On Wed, May 20, 2020 at 8:51 AM Luke Cwik  wrote:
> >>>
> >>> Rahul, do you believe that the release is severely broken without
> PR/11609 enough to require another release candidate or would waiting till
> 2.22 (which is due to be cut tomorrow)?
> >>>
> >>> On Tue, May 19, 2020 at 8:13 PM rahul patwari <
> rahulpatwari8...@gmail.com> wrote:
> 
>  Hi,
> 
>  Can the PR: https://github.com/apache/beam/pull/11609 be
> cherry-picked for 2.21.0 release?
>  If not, the fix version has to be changed for BEAM-9887.
> 
>  Regards,
>  Rahul
> 
>  On Wed, May 20, 2020 at 6:05 AM Ahmet Altay 
> wrote:
> >
> > +1, I validated python 2 and 3 quickstarts.
> >
> > On Tue, May 19, 2020 at 4:57 PM Hannah Jiang <
> hannahji...@google.com> wrote:
> >>
> >> I confirmed that licenses/notices/source code are added to Java
> and Python docker images as expected.
> >>
> >>
> >> On Tue, May 19, 2020 at 2:36 PM Kyle Weaver <
> kcwea...@google.com> wrote:
> >>>
> >>> Thanks for bringing that up Steve. I'll leave it to others to
> vote on whether that necessitates an RC #2.
> >>>
> >>> On Tue, May 19, 2020 at 5:22 PM Steve Niemitz <
>

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-21 Thread Luke Cwik

The 2.22 release is also being worked on. Rather allow that release pick up
anything that isn't critical.

On Thu, May 21, 2020 at 3:51 PM Robert Bradshaw  wrote:

> We *really* need to automate the building and deploying of artifacts,
> rather than have so many manual steps...
>
> The new set of wheels look good now. Verified all the hashes and
> signatures and source tarball contents as well. Ran a couple of test
> pipelines.
>
> I noticed https://github.com/apache/beam/pull/11722 was just merged. Are
> we OK excluding that? Other than that looks good.
>
> +1 (binding) pending the one question above.
>
> On Thu, May 21, 2020 at 10:49 AM Kyle Weaver  wrote:
>
>> Nevermind, uploading the wheels to dist.apache.org is part
>> of ./sign_hash_python_wheels.sh, which I forgot to run. Wheels should be up
>> to date now, PTAL.
>>
>> On Thu, May 21, 2020 at 1:27 PM Kyle Weaver  wrote:
>>
>>> > -1, the wheel files seem to be built against the wrong commit.
>>>
>>> Thanks for catching that Robert. I had to rebuild the wheels after some
>>> cherry picks. I validated that the wheels in gs://beam-wheels-staging are
>>> up to date. They then must not have overwritten the wheels on
>>> dist.apache.org properly, which I assume we expect the Travis build to
>>> do. I might have to copy over the new wheels myself.
>>>
>>> > Since the current RC has been -1ed maybe we can include BEAM-9887 as
>>> > part of the next RC, no?
>>>
>>> At this point, there is no need to go to a full second RC. If there turn
>>> out to be blocking issues with RC #1 that necessitate RC #2, we can
>>> consider including BEAM-9887 then.
>>>
>>> On Thu, May 21, 2020 at 3:41 AM Ismaël Mejía  wrote:
>>>
 Since the current RC has been -1ed maybe we can include BEAM-9887 as
 part of the next RC, no?
 It is definitely not a blocker but a nice to have.

 On Thu, May 21, 2020 at 2:26 AM Robert Bradshaw 
 wrote:
 >
 > -1, the wheel files seem to be built against the wrong commit. E.g.
 >
 > unzip -p
 apache_beam-2.21.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
 apache_beam/runners/worker/bundle_processor.py | head -n 40
 >
 > notice the missing "import bisect" (among other things) missing from
 https://github.com/apache/beam/blob/release-2.21.0/sdks/python/apache_beam/runners/worker/bundle_processor.py
 .
 >
 > (I do agree that BEAM-9887 isn't severe enough to hold up the release
 at this point.)
 >
 >
 > On Tue, May 19, 2020 at 8:48 PM rahul patwari <
 rahulpatwari8...@gmail.com> wrote:
 >>
 >> Hi Luke,
 >>
 >> The release is not severely broken without PR #11609.
 >> The PR ensures that, while building a Row with Logical Type, the
 input value provided is proper. If we take FixedBytes logical type with
 length 10, for example, the proper input value will be a byte array of
 length 10. But, without this PR, for FixedBytes logical type, the Row will
 be built with input value with length less than the expected length.
 >> But, as long as the input value provided is correct, there shouldn't
 be any problems.
 >> I will change the fix version as 2.22.0 for BEAM-9887.
 >>
 >> Regards,
 >> Rahul
 >>
 >> On Wed, May 20, 2020 at 8:51 AM Luke Cwik  wrote:
 >>>
 >>> Rahul, do you believe that the release is severely broken without
 PR/11609 enough to require another release candidate or would waiting till
 2.22 (which is due to be cut tomorrow)?
 >>>
 >>> On Tue, May 19, 2020 at 8:13 PM rahul patwari <
 rahulpatwari8...@gmail.com> wrote:
 
  Hi,
 
  Can the PR: https://github.com/apache/beam/pull/11609 be
 cherry-picked for 2.21.0 release?
  If not, the fix version has to be changed for BEAM-9887.
 
  Regards,
  Rahul
 
  On Wed, May 20, 2020 at 6:05 AM Ahmet Altay 
 wrote:
 >
 > +1, I validated python 2 and 3 quickstarts.
 >
 > On Tue, May 19, 2020 at 4:57 PM Hannah Jiang <
 hannahji...@google.com> wrote:
 >>
 >> I confirmed that licenses/notices/source code are added to Java
 and Python docker images as expected.
 >>
 >>
 >> On Tue, May 19, 2020 at 2:36 PM Kyle Weaver 
 wrote:
 >>>
 >>> Thanks for bringing that up Steve. I'll leave it to others to
 vote on whether that necessitates an RC #2.
 >>>
 >>> On Tue, May 19, 2020 at 5:22 PM Steve Niemitz <
 sniem...@apache.org> wrote:
 
  https://issues.apache.org/jira/browse/BEAM-10015 was marked
 as 2.21 but isn't in the RC1 tag.  It's marked as P1, and seems like the
 implication is that without the fix, pipelines can produce incorrect data.
 Is this a blocker?
 >
 >
 > +Reuven Lax, would this be a

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-21 Thread Robert Bradshaw

We *really* need to automate the building and deploying of artifacts,
rather than have so many manual steps...

The new set of wheels look good now. Verified all the hashes and signatures
and source tarball contents as well. Ran a couple of test pipelines.

I noticed https://github.com/apache/beam/pull/11722 was just merged. Are we
OK excluding that? Other than that looks good.

+1 (binding) pending the one question above.

On Thu, May 21, 2020 at 10:49 AM Kyle Weaver  wrote:

> Nevermind, uploading the wheels to dist.apache.org is part
> of ./sign_hash_python_wheels.sh, which I forgot to run. Wheels should be up
> to date now, PTAL.
>
> On Thu, May 21, 2020 at 1:27 PM Kyle Weaver  wrote:
>
>> > -1, the wheel files seem to be built against the wrong commit.
>>
>> Thanks for catching that Robert. I had to rebuild the wheels after some
>> cherry picks. I validated that the wheels in gs://beam-wheels-staging are
>> up to date. They then must not have overwritten the wheels on
>> dist.apache.org properly, which I assume we expect the Travis build to
>> do. I might have to copy over the new wheels myself.
>>
>> > Since the current RC has been -1ed maybe we can include BEAM-9887 as
>> > part of the next RC, no?
>>
>> At this point, there is no need to go to a full second RC. If there turn
>> out to be blocking issues with RC #1 that necessitate RC #2, we can
>> consider including BEAM-9887 then.
>>
>> On Thu, May 21, 2020 at 3:41 AM Ismaël Mejía  wrote:
>>
>>> Since the current RC has been -1ed maybe we can include BEAM-9887 as
>>> part of the next RC, no?
>>> It is definitely not a blocker but a nice to have.
>>>
>>> On Thu, May 21, 2020 at 2:26 AM Robert Bradshaw 
>>> wrote:
>>> >
>>> > -1, the wheel files seem to be built against the wrong commit. E.g.
>>> >
>>> > unzip -p
>>> apache_beam-2.21.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
>>> apache_beam/runners/worker/bundle_processor.py | head -n 40
>>> >
>>> > notice the missing "import bisect" (among other things) missing from
>>> https://github.com/apache/beam/blob/release-2.21.0/sdks/python/apache_beam/runners/worker/bundle_processor.py
>>> .
>>> >
>>> > (I do agree that BEAM-9887 isn't severe enough to hold up the release
>>> at this point.)
>>> >
>>> >
>>> > On Tue, May 19, 2020 at 8:48 PM rahul patwari <
>>> rahulpatwari8...@gmail.com> wrote:
>>> >>
>>> >> Hi Luke,
>>> >>
>>> >> The release is not severely broken without PR #11609.
>>> >> The PR ensures that, while building a Row with Logical Type, the
>>> input value provided is proper. If we take FixedBytes logical type with
>>> length 10, for example, the proper input value will be a byte array of
>>> length 10. But, without this PR, for FixedBytes logical type, the Row will
>>> be built with input value with length less than the expected length.
>>> >> But, as long as the input value provided is correct, there shouldn't
>>> be any problems.
>>> >> I will change the fix version as 2.22.0 for BEAM-9887.
>>> >>
>>> >> Regards,
>>> >> Rahul
>>> >>
>>> >> On Wed, May 20, 2020 at 8:51 AM Luke Cwik  wrote:
>>> >>>
>>> >>> Rahul, do you believe that the release is severely broken without
>>> PR/11609 enough to require another release candidate or would waiting till
>>> 2.22 (which is due to be cut tomorrow)?
>>> >>>
>>> >>> On Tue, May 19, 2020 at 8:13 PM rahul patwari <
>>> rahulpatwari8...@gmail.com> wrote:
>>> 
>>>  Hi,
>>> 
>>>  Can the PR: https://github.com/apache/beam/pull/11609 be
>>> cherry-picked for 2.21.0 release?
>>>  If not, the fix version has to be changed for BEAM-9887.
>>> 
>>>  Regards,
>>>  Rahul
>>> 
>>>  On Wed, May 20, 2020 at 6:05 AM Ahmet Altay 
>>> wrote:
>>> >
>>> > +1, I validated python 2 and 3 quickstarts.
>>> >
>>> > On Tue, May 19, 2020 at 4:57 PM Hannah Jiang <
>>> hannahji...@google.com> wrote:
>>> >>
>>> >> I confirmed that licenses/notices/source code are added to Java
>>> and Python docker images as expected.
>>> >>
>>> >>
>>> >> On Tue, May 19, 2020 at 2:36 PM Kyle Weaver 
>>> wrote:
>>> >>>
>>> >>> Thanks for bringing that up Steve. I'll leave it to others to
>>> vote on whether that necessitates an RC #2.
>>> >>>
>>> >>> On Tue, May 19, 2020 at 5:22 PM Steve Niemitz <
>>> sniem...@apache.org> wrote:
>>> 
>>>  https://issues.apache.org/jira/browse/BEAM-10015 was marked as
>>> 2.21 but isn't in the RC1 tag.  It's marked as P1, and seems like the
>>> implication is that without the fix, pipelines can produce incorrect data.
>>> Is this a blocker?
>>> >
>>> >
>>> > +Reuven Lax, would this be a release blocker?
>>> >
>>> 
>>> 
>>>  On Tue, May 19, 2020 at 4:51 PM Kyle Weaver <
>>> kcwea...@google.com> wrote:
>>> >
>>> > Hi everyone,
>>> > Please review and vote on the release candidate #1 for the
>>> version 2.21.0, as follows:
>>>

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-21 Thread Kyle Weaver

Nevermind, uploading the wheels to dist.apache.org is part
of ./sign_hash_python_wheels.sh, which I forgot to run. Wheels should be up
to date now, PTAL.

On Thu, May 21, 2020 at 1:27 PM Kyle Weaver  wrote:

> > -1, the wheel files seem to be built against the wrong commit.
>
> Thanks for catching that Robert. I had to rebuild the wheels after some
> cherry picks. I validated that the wheels in gs://beam-wheels-staging are
> up to date. They then must not have overwritten the wheels on
> dist.apache.org properly, which I assume we expect the Travis build to
> do. I might have to copy over the new wheels myself.
>
> > Since the current RC has been -1ed maybe we can include BEAM-9887 as
> > part of the next RC, no?
>
> At this point, there is no need to go to a full second RC. If there turn
> out to be blocking issues with RC #1 that necessitate RC #2, we can
> consider including BEAM-9887 then.
>
> On Thu, May 21, 2020 at 3:41 AM Ismaël Mejía  wrote:
>
>> Since the current RC has been -1ed maybe we can include BEAM-9887 as
>> part of the next RC, no?
>> It is definitely not a blocker but a nice to have.
>>
>> On Thu, May 21, 2020 at 2:26 AM Robert Bradshaw 
>> wrote:
>> >
>> > -1, the wheel files seem to be built against the wrong commit. E.g.
>> >
>> > unzip -p
>> apache_beam-2.21.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
>> apache_beam/runners/worker/bundle_processor.py | head -n 40
>> >
>> > notice the missing "import bisect" (among other things) missing from
>> https://github.com/apache/beam/blob/release-2.21.0/sdks/python/apache_beam/runners/worker/bundle_processor.py
>> .
>> >
>> > (I do agree that BEAM-9887 isn't severe enough to hold up the release
>> at this point.)
>> >
>> >
>> > On Tue, May 19, 2020 at 8:48 PM rahul patwari <
>> rahulpatwari8...@gmail.com> wrote:
>> >>
>> >> Hi Luke,
>> >>
>> >> The release is not severely broken without PR #11609.
>> >> The PR ensures that, while building a Row with Logical Type, the input
>> value provided is proper. If we take FixedBytes logical type with length
>> 10, for example, the proper input value will be a byte array of length 10.
>> But, without this PR, for FixedBytes logical type, the Row will be built
>> with input value with length less than the expected length.
>> >> But, as long as the input value provided is correct, there shouldn't
>> be any problems.
>> >> I will change the fix version as 2.22.0 for BEAM-9887.
>> >>
>> >> Regards,
>> >> Rahul
>> >>
>> >> On Wed, May 20, 2020 at 8:51 AM Luke Cwik  wrote:
>> >>>
>> >>> Rahul, do you believe that the release is severely broken without
>> PR/11609 enough to require another release candidate or would waiting till
>> 2.22 (which is due to be cut tomorrow)?
>> >>>
>> >>> On Tue, May 19, 2020 at 8:13 PM rahul patwari <
>> rahulpatwari8...@gmail.com> wrote:
>> 
>>  Hi,
>> 
>>  Can the PR: https://github.com/apache/beam/pull/11609 be
>> cherry-picked for 2.21.0 release?
>>  If not, the fix version has to be changed for BEAM-9887.
>> 
>>  Regards,
>>  Rahul
>> 
>>  On Wed, May 20, 2020 at 6:05 AM Ahmet Altay 
>> wrote:
>> >
>> > +1, I validated python 2 and 3 quickstarts.
>> >
>> > On Tue, May 19, 2020 at 4:57 PM Hannah Jiang <
>> hannahji...@google.com> wrote:
>> >>
>> >> I confirmed that licenses/notices/source code are added to Java
>> and Python docker images as expected.
>> >>
>> >>
>> >> On Tue, May 19, 2020 at 2:36 PM Kyle Weaver 
>> wrote:
>> >>>
>> >>> Thanks for bringing that up Steve. I'll leave it to others to
>> vote on whether that necessitates an RC #2.
>> >>>
>> >>> On Tue, May 19, 2020 at 5:22 PM Steve Niemitz <
>> sniem...@apache.org> wrote:
>> 
>>  https://issues.apache.org/jira/browse/BEAM-10015 was marked as
>> 2.21 but isn't in the RC1 tag.  It's marked as P1, and seems like the
>> implication is that without the fix, pipelines can produce incorrect data.
>> Is this a blocker?
>> >
>> >
>> > +Reuven Lax, would this be a release blocker?
>> >
>> 
>> 
>>  On Tue, May 19, 2020 at 4:51 PM Kyle Weaver 
>> wrote:
>> >
>> > Hi everyone,
>> > Please review and vote on the release candidate #1 for the
>> version 2.21.0, as follows:
>> > [ ] +1, Approve the release
>> > [ ] -1, Do not approve the release (please provide specific
>> comments)
>> >
>> >
>> > The complete staging area is available for your review, which
>> includes:
>> > * JIRA release notes [1],
>> > * the official Apache source release to be deployed to
>> dist.apache.org [2], which is signed with the key with fingerprint
>> F11E37D7F006D086232876797B6D6673C79AEA72 [3],
>> > * all artifacts to be deployed to the Maven Central Repository
>> [4],
>> > * source code tag "v2.21.0-RC1" [5],
>> > * website pull

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-21 Thread Kyle Weaver

> -1, the wheel files seem to be built against the wrong commit.

Thanks for catching that Robert. I had to rebuild the wheels after some
cherry picks. I validated that the wheels in gs://beam-wheels-staging are
up to date. They then must not have overwritten the wheels on
dist.apache.org properly, which I assume we expect the Travis build to do.
I might have to copy over the new wheels myself.

> Since the current RC has been -1ed maybe we can include BEAM-9887 as
> part of the next RC, no?

At this point, there is no need to go to a full second RC. If there turn
out to be blocking issues with RC #1 that necessitate RC #2, we can
consider including BEAM-9887 then.

On Thu, May 21, 2020 at 3:41 AM Ismaël Mejía  wrote:

> Since the current RC has been -1ed maybe we can include BEAM-9887 as
> part of the next RC, no?
> It is definitely not a blocker but a nice to have.
>
> On Thu, May 21, 2020 at 2:26 AM Robert Bradshaw 
> wrote:
> >
> > -1, the wheel files seem to be built against the wrong commit. E.g.
> >
> > unzip -p
> apache_beam-2.21.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> apache_beam/runners/worker/bundle_processor.py | head -n 40
> >
> > notice the missing "import bisect" (among other things) missing from
> https://github.com/apache/beam/blob/release-2.21.0/sdks/python/apache_beam/runners/worker/bundle_processor.py
> .
> >
> > (I do agree that BEAM-9887 isn't severe enough to hold up the release at
> this point.)
> >
> >
> > On Tue, May 19, 2020 at 8:48 PM rahul patwari <
> rahulpatwari8...@gmail.com> wrote:
> >>
> >> Hi Luke,
> >>
> >> The release is not severely broken without PR #11609.
> >> The PR ensures that, while building a Row with Logical Type, the input
> value provided is proper. If we take FixedBytes logical type with length
> 10, for example, the proper input value will be a byte array of length 10.
> But, without this PR, for FixedBytes logical type, the Row will be built
> with input value with length less than the expected length.
> >> But, as long as the input value provided is correct, there shouldn't be
> any problems.
> >> I will change the fix version as 2.22.0 for BEAM-9887.
> >>
> >> Regards,
> >> Rahul
> >>
> >> On Wed, May 20, 2020 at 8:51 AM Luke Cwik  wrote:
> >>>
> >>> Rahul, do you believe that the release is severely broken without
> PR/11609 enough to require another release candidate or would waiting till
> 2.22 (which is due to be cut tomorrow)?
> >>>
> >>> On Tue, May 19, 2020 at 8:13 PM rahul patwari <
> rahulpatwari8...@gmail.com> wrote:
> 
>  Hi,
> 
>  Can the PR: https://github.com/apache/beam/pull/11609 be
> cherry-picked for 2.21.0 release?
>  If not, the fix version has to be changed for BEAM-9887.
> 
>  Regards,
>  Rahul
> 
>  On Wed, May 20, 2020 at 6:05 AM Ahmet Altay  wrote:
> >
> > +1, I validated python 2 and 3 quickstarts.
> >
> > On Tue, May 19, 2020 at 4:57 PM Hannah Jiang 
> wrote:
> >>
> >> I confirmed that licenses/notices/source code are added to Java and
> Python docker images as expected.
> >>
> >>
> >> On Tue, May 19, 2020 at 2:36 PM Kyle Weaver 
> wrote:
> >>>
> >>> Thanks for bringing that up Steve. I'll leave it to others to vote
> on whether that necessitates an RC #2.
> >>>
> >>> On Tue, May 19, 2020 at 5:22 PM Steve Niemitz 
> wrote:
> 
>  https://issues.apache.org/jira/browse/BEAM-10015 was marked as
> 2.21 but isn't in the RC1 tag.  It's marked as P1, and seems like the
> implication is that without the fix, pipelines can produce incorrect data.
> Is this a blocker?
> >
> >
> > +Reuven Lax, would this be a release blocker?
> >
> 
> 
>  On Tue, May 19, 2020 at 4:51 PM Kyle Weaver 
> wrote:
> >
> > Hi everyone,
> > Please review and vote on the release candidate #1 for the
> version 2.21.0, as follows:
> > [ ] +1, Approve the release
> > [ ] -1, Do not approve the release (please provide specific
> comments)
> >
> >
> > The complete staging area is available for your review, which
> includes:
> > * JIRA release notes [1],
> > * the official Apache source release to be deployed to
> dist.apache.org [2], which is signed with the key with fingerprint
> F11E37D7F006D086232876797B6D6673C79AEA72 [3],
> > * all artifacts to be deployed to the Maven Central Repository
> [4],
> > * source code tag "v2.21.0-RC1" [5],
> > * website pull request listing the release [6], publishing the
> API reference manual [7], and the blog post [8].
> > * Java artifacts were built with Maven 3.6.3 and OpenJDK/Oracle
> JDK 1.8.0.
> > * Python artifacts are deployed along with the source release to
> the dist.apache.org [2].
> > * Validation sheet with a tab for 2.21.0 release to help with
> validation [9].
> > *

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-21 Thread Ismaël Mejía

Since the current RC has been -1ed maybe we can include BEAM-9887 as
part of the next RC, no?
It is definitely not a blocker but a nice to have.

On Thu, May 21, 2020 at 2:26 AM Robert Bradshaw  wrote:
>
> -1, the wheel files seem to be built against the wrong commit. E.g.
>
> unzip -p 
> apache_beam-2.21.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
>  apache_beam/runners/worker/bundle_processor.py | head -n 40
>
> notice the missing "import bisect" (among other things) missing from 
> https://github.com/apache/beam/blob/release-2.21.0/sdks/python/apache_beam/runners/worker/bundle_processor.py.
>
> (I do agree that BEAM-9887 isn't severe enough to hold up the release at this 
> point.)
>
>
> On Tue, May 19, 2020 at 8:48 PM rahul patwari  
> wrote:
>>
>> Hi Luke,
>>
>> The release is not severely broken without PR #11609.
>> The PR ensures that, while building a Row with Logical Type, the input value 
>> provided is proper. If we take FixedBytes logical type with length 10, for 
>> example, the proper input value will be a byte array of length 10. But, 
>> without this PR, for FixedBytes logical type, the Row will be built with 
>> input value with length less than the expected length.
>> But, as long as the input value provided is correct, there shouldn't be any 
>> problems.
>> I will change the fix version as 2.22.0 for BEAM-9887.
>>
>> Regards,
>> Rahul
>>
>> On Wed, May 20, 2020 at 8:51 AM Luke Cwik  wrote:
>>>
>>> Rahul, do you believe that the release is severely broken without PR/11609 
>>> enough to require another release candidate or would waiting till 2.22 
>>> (which is due to be cut tomorrow)?
>>>
>>> On Tue, May 19, 2020 at 8:13 PM rahul patwari  
>>> wrote:

 Hi,

 Can the PR: https://github.com/apache/beam/pull/11609 be cherry-picked for 
 2.21.0 release?
 If not, the fix version has to be changed for BEAM-9887.

 Regards,
 Rahul

 On Wed, May 20, 2020 at 6:05 AM Ahmet Altay  wrote:
>
> +1, I validated python 2 and 3 quickstarts.
>
> On Tue, May 19, 2020 at 4:57 PM Hannah Jiang  
> wrote:
>>
>> I confirmed that licenses/notices/source code are added to Java and 
>> Python docker images as expected.
>>
>>
>> On Tue, May 19, 2020 at 2:36 PM Kyle Weaver  wrote:
>>>
>>> Thanks for bringing that up Steve. I'll leave it to others to vote on 
>>> whether that necessitates an RC #2.
>>>
>>> On Tue, May 19, 2020 at 5:22 PM Steve Niemitz  
>>> wrote:

 https://issues.apache.org/jira/browse/BEAM-10015 was marked as 2.21 
 but isn't in the RC1 tag.  It's marked as P1, and seems like the 
 implication is that without the fix, pipelines can produce incorrect 
 data.  Is this a blocker?
>
>
> +Reuven Lax, would this be a release blocker?
>


 On Tue, May 19, 2020 at 4:51 PM Kyle Weaver  
 wrote:
>
> Hi everyone,
> Please review and vote on the release candidate #1 for the version 
> 2.21.0, as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
>
> The complete staging area is available for your review, which 
> includes:
> * JIRA release notes [1],
> * the official Apache source release to be deployed to 
> dist.apache.org [2], which is signed with the key with fingerprint 
> F11E37D7F006D086232876797B6D6673C79AEA72 [3],
> * all artifacts to be deployed to the Maven Central Repository [4],
> * source code tag "v2.21.0-RC1" [5],
> * website pull request listing the release [6], publishing the API 
> reference manual [7], and the blog post [8].
> * Java artifacts were built with Maven 3.6.3 and OpenJDK/Oracle JDK 
> 1.8.0.
> * Python artifacts are deployed along with the source release to the 
> dist.apache.org [2].
> * Validation sheet with a tab for 2.21.0 release to help with 
> validation [9].
> * Docker images published to Docker Hub [10].
>
> The vote will be open for at least 72 hours. It is adopted by 
> majority approval, with at least 3 PMC affirmative votes.
>
> Thanks,
> Kyle
>
> [1] 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527=12347143
> [2] https://dist.apache.org/repos/dist/dev/beam/2.21.0/
> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
> [4] 
> https://repository.apache.org/content/repositories/orgapachebeam-1103/
> [5] https://github.com/apache/beam/releases/tag/v2.21.0-RC1
> [6] https://github.com/apache/beam/pull/11727
> [7] https://github.com/apache/beam-site/pull/603
> [8]

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-20 Thread Robert Bradshaw

-1, the wheel files seem to be built against the wrong commit. E.g.

unzip -p
apache_beam-2.21.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
apache_beam/runners/worker/bundle_processor.py | head -n 40

notice the missing "import bisect" (among other things) missing from
https://github.com/apache/beam/blob/release-2.21.0/sdks/python/apache_beam/runners/worker/bundle_processor.py
.

(I do agree that BEAM-9887 isn't severe enough to hold up the release at
this point.)


On Tue, May 19, 2020 at 8:48 PM rahul patwari 
wrote:

> Hi Luke,
>
> The release is not severely broken without PR #11609.
> The PR ensures that, while building a Row with Logical Type, the input
> value provided is proper. If we take FixedBytes logical type with length
> 10, for example, the proper input value will be a byte array of length 10.
> But, without this PR, for FixedBytes logical type, the Row will be built
> with input value with length less than the expected length.
> But, as long as the input value provided is correct, there shouldn't be
> any problems.
> I will change the fix version as 2.22.0 for BEAM-9887
> .
>
> Regards,
> Rahul
>
> On Wed, May 20, 2020 at 8:51 AM Luke Cwik  wrote:
>
>> Rahul, do you believe that the release is severely broken without
>> PR/11609 enough to require another release candidate or would waiting till
>> 2.22 (which is due to be cut tomorrow)?
>>
>> On Tue, May 19, 2020 at 8:13 PM rahul patwari 
>> wrote:
>>
>>> Hi,
>>>
>>> Can the PR: https://github.com/apache/beam/pull/11609 be cherry-picked
>>> for 2.21.0 release?
>>> If not, the fix version has to be changed for BEAM-9887
>>> .
>>>
>>> Regards,
>>> Rahul
>>>
>>> On Wed, May 20, 2020 at 6:05 AM Ahmet Altay  wrote:
>>>
 +1, I validated python 2 and 3 quickstarts.

 On Tue, May 19, 2020 at 4:57 PM Hannah Jiang 
 wrote:

> I confirmed that licenses/notices/source code are added to Java and
> Python docker images as expected.
>
>
> On Tue, May 19, 2020 at 2:36 PM Kyle Weaver 
> wrote:
>
>> Thanks for bringing that up Steve. I'll leave it to others to vote on
>> whether that necessitates an RC #2.
>>
>> On Tue, May 19, 2020 at 5:22 PM Steve Niemitz 
>> wrote:
>>
>>> https://issues.apache.org/jira/browse/BEAM-10015 was marked as 2.21
>>> but isn't in the RC1 tag.  It's marked as P1, and seems like the
>>> implication is that without the fix, pipelines can produce incorrect 
>>> data.
>>> Is this a blocker?
>>>
>>
 +Reuven Lax , would this be a release blocker?


>
>>> On Tue, May 19, 2020 at 4:51 PM Kyle Weaver 
>>> wrote:
>>>
 Hi everyone,
 Please review and vote on the release candidate #1 for the version
 2.21.0, as follows:
 [ ] +1, Approve the release
 [ ] -1, Do not approve the release (please provide specific
 comments)


 The complete staging area is available for your review, which
 includes:
 * JIRA release notes [1],
 * the official Apache source release to be deployed to
 dist.apache.org [2], which is signed with the key with fingerprint
 F11E37D7F006D086232876797B6D6673C79AEA72 [3],
 * all artifacts to be deployed to the Maven Central Repository [4],
 * source code tag "v2.21.0-RC1" [5],
 * website pull request listing the release [6], publishing the API
 reference manual [7], and the blog post [8].
 * Java artifacts were built with Maven 3.6.3 and OpenJDK/Oracle JDK
 1.8.0.
 * Python artifacts are deployed along with the source release to
 the dist.apache.org [2].
 * Validation sheet with a tab for 2.21.0 release to help with
 validation [9].
 * Docker images published to Docker Hub [10].

 The vote will be open for at least 72 hours. It is adopted by
 majority approval, with at least 3 PMC affirmative votes.

 Thanks,
 Kyle

 [1]
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527=12347143
 [2] https://dist.apache.org/repos/dist/dev/beam/2.21.0/
 [3] https://dist.apache.org/repos/dist/release/beam/KEYS
 [4]
 https://repository.apache.org/content/repositories/orgapachebeam-1103/
 [5] https://github.com/apache/beam/releases/tag/v2.21.0-RC1
 [6] https://github.com/apache/beam/pull/11727
 [7] https://github.com/apache/beam-site/pull/603
 [8] https://github.com/apache/beam/pull/11729
 [9]
 https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=275707202
 [10] https://hub.docker.com/search?q=apache%2Fbeam=image

>>>

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-19 Thread rahul patwari

Hi Luke,

The release is not severely broken without PR #11609.
The PR ensures that, while building a Row with Logical Type, the input
value provided is proper. If we take FixedBytes logical type with length
10, for example, the proper input value will be a byte array of length 10.
But, without this PR, for FixedBytes logical type, the Row will be built
with input value with length less than the expected length.
But, as long as the input value provided is correct, there shouldn't be any
problems.
I will change the fix version as 2.22.0 for BEAM-9887
.

Regards,
Rahul

On Wed, May 20, 2020 at 8:51 AM Luke Cwik  wrote:

> Rahul, do you believe that the release is severely broken without PR/11609
> enough to require another release candidate or would waiting till 2.22
> (which is due to be cut tomorrow)?
>
> On Tue, May 19, 2020 at 8:13 PM rahul patwari 
> wrote:
>
>> Hi,
>>
>> Can the PR: https://github.com/apache/beam/pull/11609 be cherry-picked
>> for 2.21.0 release?
>> If not, the fix version has to be changed for BEAM-9887
>> .
>>
>> Regards,
>> Rahul
>>
>> On Wed, May 20, 2020 at 6:05 AM Ahmet Altay  wrote:
>>
>>> +1, I validated python 2 and 3 quickstarts.
>>>
>>> On Tue, May 19, 2020 at 4:57 PM Hannah Jiang 
>>> wrote:
>>>
 I confirmed that licenses/notices/source code are added to Java and
 Python docker images as expected.


 On Tue, May 19, 2020 at 2:36 PM Kyle Weaver 
 wrote:

> Thanks for bringing that up Steve. I'll leave it to others to vote on
> whether that necessitates an RC #2.
>
> On Tue, May 19, 2020 at 5:22 PM Steve Niemitz 
> wrote:
>
>> https://issues.apache.org/jira/browse/BEAM-10015 was marked as 2.21
>> but isn't in the RC1 tag.  It's marked as P1, and seems like the
>> implication is that without the fix, pipelines can produce incorrect 
>> data.
>> Is this a blocker?
>>
>
>>> +Reuven Lax , would this be a release blocker?
>>>
>>>

>> On Tue, May 19, 2020 at 4:51 PM Kyle Weaver 
>> wrote:
>>
>>> Hi everyone,
>>> Please review and vote on the release candidate #1 for the version
>>> 2.21.0, as follows:
>>> [ ] +1, Approve the release
>>> [ ] -1, Do not approve the release (please provide specific comments)
>>>
>>>
>>> The complete staging area is available for your review, which
>>> includes:
>>> * JIRA release notes [1],
>>> * the official Apache source release to be deployed to
>>> dist.apache.org [2], which is signed with the key with fingerprint
>>> F11E37D7F006D086232876797B6D6673C79AEA72 [3],
>>> * all artifacts to be deployed to the Maven Central Repository [4],
>>> * source code tag "v2.21.0-RC1" [5],
>>> * website pull request listing the release [6], publishing the API
>>> reference manual [7], and the blog post [8].
>>> * Java artifacts were built with Maven 3.6.3 and OpenJDK/Oracle JDK
>>> 1.8.0.
>>> * Python artifacts are deployed along with the source release to the
>>> dist.apache.org [2].
>>> * Validation sheet with a tab for 2.21.0 release to help with
>>> validation [9].
>>> * Docker images published to Docker Hub [10].
>>>
>>> The vote will be open for at least 72 hours. It is adopted by
>>> majority approval, with at least 3 PMC affirmative votes.
>>>
>>> Thanks,
>>> Kyle
>>>
>>> [1]
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527=12347143
>>> [2] https://dist.apache.org/repos/dist/dev/beam/2.21.0/
>>> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
>>> [4]
>>> https://repository.apache.org/content/repositories/orgapachebeam-1103/
>>> [5] https://github.com/apache/beam/releases/tag/v2.21.0-RC1
>>> [6] https://github.com/apache/beam/pull/11727
>>> [7] https://github.com/apache/beam-site/pull/603
>>> [8] https://github.com/apache/beam/pull/11729
>>> [9]
>>> https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=275707202
>>> [10] https://hub.docker.com/search?q=apache%2Fbeam=image
>>>
>>

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-19 Thread Luke Cwik

Rahul, do you believe that the release is severely broken without PR/11609
enough to require another release candidate or would waiting till 2.22
(which is due to be cut tomorrow)?

On Tue, May 19, 2020 at 8:13 PM rahul patwari 
wrote:

> Hi,
>
> Can the PR: https://github.com/apache/beam/pull/11609 be cherry-picked
> for 2.21.0 release?
> If not, the fix version has to be changed for BEAM-9887
> .
>
> Regards,
> Rahul
>
> On Wed, May 20, 2020 at 6:05 AM Ahmet Altay  wrote:
>
>> +1, I validated python 2 and 3 quickstarts.
>>
>> On Tue, May 19, 2020 at 4:57 PM Hannah Jiang 
>> wrote:
>>
>>> I confirmed that licenses/notices/source code are added to Java and
>>> Python docker images as expected.
>>>
>>>
>>> On Tue, May 19, 2020 at 2:36 PM Kyle Weaver  wrote:
>>>
 Thanks for bringing that up Steve. I'll leave it to others to vote on
 whether that necessitates an RC #2.

 On Tue, May 19, 2020 at 5:22 PM Steve Niemitz 
 wrote:

> https://issues.apache.org/jira/browse/BEAM-10015 was marked as 2.21
> but isn't in the RC1 tag.  It's marked as P1, and seems like the
> implication is that without the fix, pipelines can produce incorrect data.
> Is this a blocker?
>

>> +Reuven Lax , would this be a release blocker?
>>
>>
>>>
> On Tue, May 19, 2020 at 4:51 PM Kyle Weaver 
> wrote:
>
>> Hi everyone,
>> Please review and vote on the release candidate #1 for the version
>> 2.21.0, as follows:
>> [ ] +1, Approve the release
>> [ ] -1, Do not approve the release (please provide specific comments)
>>
>>
>> The complete staging area is available for your review, which
>> includes:
>> * JIRA release notes [1],
>> * the official Apache source release to be deployed to
>> dist.apache.org [2], which is signed with the key with fingerprint
>> F11E37D7F006D086232876797B6D6673C79AEA72 [3],
>> * all artifacts to be deployed to the Maven Central Repository [4],
>> * source code tag "v2.21.0-RC1" [5],
>> * website pull request listing the release [6], publishing the API
>> reference manual [7], and the blog post [8].
>> * Java artifacts were built with Maven 3.6.3 and OpenJDK/Oracle JDK
>> 1.8.0.
>> * Python artifacts are deployed along with the source release to the
>> dist.apache.org [2].
>> * Validation sheet with a tab for 2.21.0 release to help with
>> validation [9].
>> * Docker images published to Docker Hub [10].
>>
>> The vote will be open for at least 72 hours. It is adopted by
>> majority approval, with at least 3 PMC affirmative votes.
>>
>> Thanks,
>> Kyle
>>
>> [1]
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527=12347143
>> [2] https://dist.apache.org/repos/dist/dev/beam/2.21.0/
>> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
>> [4]
>> https://repository.apache.org/content/repositories/orgapachebeam-1103/
>> [5] https://github.com/apache/beam/releases/tag/v2.21.0-RC1
>> [6] https://github.com/apache/beam/pull/11727
>> [7] https://github.com/apache/beam-site/pull/603
>> [8] https://github.com/apache/beam/pull/11729
>> [9]
>> https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=275707202
>> [10] https://hub.docker.com/search?q=apache%2Fbeam=image
>>
>

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-19 Thread rahul patwari

Hi,

Can the PR: https://github.com/apache/beam/pull/11609 be cherry-picked for
2.21.0 release?
If not, the fix version has to be changed for BEAM-9887
.

Regards,
Rahul

On Wed, May 20, 2020 at 6:05 AM Ahmet Altay  wrote:

> +1, I validated python 2 and 3 quickstarts.
>
> On Tue, May 19, 2020 at 4:57 PM Hannah Jiang 
> wrote:
>
>> I confirmed that licenses/notices/source code are added to Java and
>> Python docker images as expected.
>>
>>
>> On Tue, May 19, 2020 at 2:36 PM Kyle Weaver  wrote:
>>
>>> Thanks for bringing that up Steve. I'll leave it to others to vote on
>>> whether that necessitates an RC #2.
>>>
>>> On Tue, May 19, 2020 at 5:22 PM Steve Niemitz 
>>> wrote:
>>>
 https://issues.apache.org/jira/browse/BEAM-10015 was marked as 2.21
 but isn't in the RC1 tag.  It's marked as P1, and seems like the
 implication is that without the fix, pipelines can produce incorrect data.
 Is this a blocker?

>>>
> +Reuven Lax , would this be a release blocker?
>
>
>>
 On Tue, May 19, 2020 at 4:51 PM Kyle Weaver 
 wrote:

> Hi everyone,
> Please review and vote on the release candidate #1 for the version
> 2.21.0, as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
>
> The complete staging area is available for your review, which includes:
> * JIRA release notes [1],
> * the official Apache source release to be deployed to dist.apache.org
> [2], which is signed with the key with fingerprint
> F11E37D7F006D086232876797B6D6673C79AEA72 [3],
> * all artifacts to be deployed to the Maven Central Repository [4],
> * source code tag "v2.21.0-RC1" [5],
> * website pull request listing the release [6], publishing the API
> reference manual [7], and the blog post [8].
> * Java artifacts were built with Maven 3.6.3 and OpenJDK/Oracle JDK
> 1.8.0.
> * Python artifacts are deployed along with the source release to the
> dist.apache.org [2].
> * Validation sheet with a tab for 2.21.0 release to help with
> validation [9].
> * Docker images published to Docker Hub [10].
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Thanks,
> Kyle
>
> [1]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527=12347143
> [2] https://dist.apache.org/repos/dist/dev/beam/2.21.0/
> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
> [4]
> https://repository.apache.org/content/repositories/orgapachebeam-1103/
> [5] https://github.com/apache/beam/releases/tag/v2.21.0-RC1
> [6] https://github.com/apache/beam/pull/11727
> [7] https://github.com/apache/beam-site/pull/603
> [8] https://github.com/apache/beam/pull/11729
> [9]
> https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=275707202
> [10] https://hub.docker.com/search?q=apache%2Fbeam=image
>

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-19 Thread Ahmet Altay

+1, I validated python 2 and 3 quickstarts.

On Tue, May 19, 2020 at 4:57 PM Hannah Jiang  wrote:

> I confirmed that licenses/notices/source code are added to Java and Python
> docker images as expected.
>
>
> On Tue, May 19, 2020 at 2:36 PM Kyle Weaver  wrote:
>
>> Thanks for bringing that up Steve. I'll leave it to others to vote on
>> whether that necessitates an RC #2.
>>
>> On Tue, May 19, 2020 at 5:22 PM Steve Niemitz 
>> wrote:
>>
>>> https://issues.apache.org/jira/browse/BEAM-10015 was marked as 2.21 but
>>> isn't in the RC1 tag.  It's marked as P1, and seems like the implication is
>>> that without the fix, pipelines can produce incorrect data.  Is this a
>>> blocker?
>>>
>>
+Reuven Lax , would this be a release blocker?

>
>>> On Tue, May 19, 2020 at 4:51 PM Kyle Weaver  wrote:
>>>
 Hi everyone,
 Please review and vote on the release candidate #1 for the version
 2.21.0, as follows:
 [ ] +1, Approve the release
 [ ] -1, Do not approve the release (please provide specific comments)

 The complete staging area is available for your review, which includes:
 * JIRA release notes [1],
 * the official Apache source release to be deployed to dist.apache.org
 [2], which is signed with the key with fingerprint
 F11E37D7F006D086232876797B6D6673C79AEA72 [3],
 * all artifacts to be deployed to the Maven Central Repository [4],
 * source code tag "v2.21.0-RC1" [5],
 * website pull request listing the release [6], publishing the API
 reference manual [7], and the blog post [8].
 * Java artifacts were built with Maven 3.6.3 and OpenJDK/Oracle JDK
 1.8.0.
 * Python artifacts are deployed along with the source release to the
 dist.apache.org [2].
 * Validation sheet with a tab for 2.21.0 release to help with
 validation [9].
 * Docker images published to Docker Hub [10].

 The vote will be open for at least 72 hours. It is adopted by majority
 approval, with at least 3 PMC affirmative votes.

 Thanks,
 Kyle

 [1]
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527=12347143
 [2] https://dist.apache.org/repos/dist/dev/beam/2.21.0/
 [3] https://dist.apache.org/repos/dist/release/beam/KEYS
 [4]
 https://repository.apache.org/content/repositories/orgapachebeam-1103/
 [5] https://github.com/apache/beam/releases/tag/v2.21.0-RC1
 [6] https://github.com/apache/beam/pull/11727
 [7] https://github.com/apache/beam-site/pull/603
 [8] https://github.com/apache/beam/pull/11729
 [9]
 https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=275707202
 [10] https://hub.docker.com/search?q=apache%2Fbeam=image

>>>

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-19 Thread Hannah Jiang

I confirmed that licenses/notices/source code are added to Java and Python
docker images as expected.


On Tue, May 19, 2020 at 2:36 PM Kyle Weaver  wrote:

> Thanks for bringing that up Steve. I'll leave it to others to vote on
> whether that necessitates an RC #2.
>
> On Tue, May 19, 2020 at 5:22 PM Steve Niemitz  wrote:
>
>> https://issues.apache.org/jira/browse/BEAM-10015 was marked as 2.21 but
>> isn't in the RC1 tag.  It's marked as P1, and seems like the implication is
>> that without the fix, pipelines can produce incorrect data.  Is this a
>> blocker?
>>
>> On Tue, May 19, 2020 at 4:51 PM Kyle Weaver  wrote:
>>
>>> Hi everyone,
>>> Please review and vote on the release candidate #1 for the version
>>> 2.21.0, as follows:
>>> [ ] +1, Approve the release
>>> [ ] -1, Do not approve the release (please provide specific comments)
>>>
>>>
>>> The complete staging area is available for your review, which includes:
>>> * JIRA release notes [1],
>>> * the official Apache source release to be deployed to dist.apache.org
>>> [2], which is signed with the key with fingerprint
>>> F11E37D7F006D086232876797B6D6673C79AEA72 [3],
>>> * all artifacts to be deployed to the Maven Central Repository [4],
>>> * source code tag "v2.21.0-RC1" [5],
>>> * website pull request listing the release [6], publishing the API
>>> reference manual [7], and the blog post [8].
>>> * Java artifacts were built with Maven 3.6.3 and OpenJDK/Oracle JDK
>>> 1.8.0.
>>> * Python artifacts are deployed along with the source release to the
>>> dist.apache.org [2].
>>> * Validation sheet with a tab for 2.21.0 release to help with validation
>>> [9].
>>> * Docker images published to Docker Hub [10].
>>>
>>> The vote will be open for at least 72 hours. It is adopted by majority
>>> approval, with at least 3 PMC affirmative votes.
>>>
>>> Thanks,
>>> Kyle
>>>
>>> [1]
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527=12347143
>>> [2] https://dist.apache.org/repos/dist/dev/beam/2.21.0/
>>> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
>>> [4]
>>> https://repository.apache.org/content/repositories/orgapachebeam-1103/
>>> [5] https://github.com/apache/beam/releases/tag/v2.21.0-RC1
>>> [6] https://github.com/apache/beam/pull/11727
>>> [7] https://github.com/apache/beam-site/pull/603
>>> [8] https://github.com/apache/beam/pull/11729
>>> [9]
>>> https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=275707202
>>> [10] https://hub.docker.com/search?q=apache%2Fbeam=image
>>>
>>

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-19 Thread Kyle Weaver

Thanks for bringing that up Steve. I'll leave it to others to vote on
whether that necessitates an RC #2.

On Tue, May 19, 2020 at 5:22 PM Steve Niemitz  wrote:

> https://issues.apache.org/jira/browse/BEAM-10015 was marked as 2.21 but
> isn't in the RC1 tag.  It's marked as P1, and seems like the implication is
> that without the fix, pipelines can produce incorrect data.  Is this a
> blocker?
>
> On Tue, May 19, 2020 at 4:51 PM Kyle Weaver  wrote:
>
>> Hi everyone,
>> Please review and vote on the release candidate #1 for the version
>> 2.21.0, as follows:
>> [ ] +1, Approve the release
>> [ ] -1, Do not approve the release (please provide specific comments)
>>
>>
>> The complete staging area is available for your review, which includes:
>> * JIRA release notes [1],
>> * the official Apache source release to be deployed to dist.apache.org
>> [2], which is signed with the key with fingerprint
>> F11E37D7F006D086232876797B6D6673C79AEA72 [3],
>> * all artifacts to be deployed to the Maven Central Repository [4],
>> * source code tag "v2.21.0-RC1" [5],
>> * website pull request listing the release [6], publishing the API
>> reference manual [7], and the blog post [8].
>> * Java artifacts were built with Maven 3.6.3 and OpenJDK/Oracle JDK 1.8.0.
>> * Python artifacts are deployed along with the source release to the
>> dist.apache.org [2].
>> * Validation sheet with a tab for 2.21.0 release to help with validation
>> [9].
>> * Docker images published to Docker Hub [10].
>>
>> The vote will be open for at least 72 hours. It is adopted by majority
>> approval, with at least 3 PMC affirmative votes.
>>
>> Thanks,
>> Kyle
>>
>> [1]
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527=12347143
>> [2] https://dist.apache.org/repos/dist/dev/beam/2.21.0/
>> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
>> [4]
>> https://repository.apache.org/content/repositories/orgapachebeam-1103/
>> [5] https://github.com/apache/beam/releases/tag/v2.21.0-RC1
>> [6] https://github.com/apache/beam/pull/11727
>> [7] https://github.com/apache/beam-site/pull/603
>> [8] https://github.com/apache/beam/pull/11729
>> [9]
>> https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=275707202
>> [10] https://hub.docker.com/search?q=apache%2Fbeam=image
>>
>

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-19 Thread Steve Niemitz

https://issues.apache.org/jira/browse/BEAM-10015 was marked as 2.21 but
isn't in the RC1 tag.  It's marked as P1, and seems like the implication is
that without the fix, pipelines can produce incorrect data.  Is this a
blocker?

On Tue, May 19, 2020 at 4:51 PM Kyle Weaver  wrote:

> Hi everyone,
> Please review and vote on the release candidate #1 for the version 2.21.0,
> as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
>
> The complete staging area is available for your review, which includes:
> * JIRA release notes [1],
> * the official Apache source release to be deployed to dist.apache.org
> [2], which is signed with the key with fingerprint
> F11E37D7F006D086232876797B6D6673C79AEA72 [3],
> * all artifacts to be deployed to the Maven Central Repository [4],
> * source code tag "v2.21.0-RC1" [5],
> * website pull request listing the release [6], publishing the API
> reference manual [7], and the blog post [8].
> * Java artifacts were built with Maven 3.6.3 and OpenJDK/Oracle JDK 1.8.0.
> * Python artifacts are deployed along with the source release to the
> dist.apache.org [2].
> * Validation sheet with a tab for 2.21.0 release to help with validation
> [9].
> * Docker images published to Docker Hub [10].
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Thanks,
> Kyle
>
> [1]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527=12347143
> [2] https://dist.apache.org/repos/dist/dev/beam/2.21.0/
> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
> [4] https://repository.apache.org/content/repositories/orgapachebeam-1103/
> [5] https://github.com/apache/beam/releases/tag/v2.21.0-RC1
> [6] https://github.com/apache/beam/pull/11727
> [7] https://github.com/apache/beam-site/pull/603
> [8] https://github.com/apache/beam/pull/11729
> [9]
> https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=275707202
> [10] https://hub.docker.com/search?q=apache%2Fbeam=image
>

Re: [VOTE] Release 2.21.0, release candidate #1

2020-05-19 Thread Luke Cwik

+1 (binding)

Verified:
* Signatures and file hashes
* Java quickstarts on local cluster runners and Dataflow.

On Tue, May 19, 2020 at 1:51 PM Kyle Weaver  wrote:

> Hi everyone,
> Please review and vote on the release candidate #1 for the version 2.21.0,
> as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
>
> The complete staging area is available for your review, which includes:
> * JIRA release notes [1],
> * the official Apache source release to be deployed to dist.apache.org
> [2], which is signed with the key with fingerprint
> F11E37D7F006D086232876797B6D6673C79AEA72 [3],
> * all artifacts to be deployed to the Maven Central Repository [4],
> * source code tag "v2.21.0-RC1" [5],
> * website pull request listing the release [6], publishing the API
> reference manual [7], and the blog post [8].
> * Java artifacts were built with Maven 3.6.3 and OpenJDK/Oracle JDK 1.8.0.
> * Python artifacts are deployed along with the source release to the
> dist.apache.org [2].
> * Validation sheet with a tab for 2.21.0 release to help with validation
> [9].
> * Docker images published to Docker Hub [10].
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Thanks,
> Kyle
>
> [1]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527=12347143
> [2] https://dist.apache.org/repos/dist/dev/beam/2.21.0/
> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
> [4] https://repository.apache.org/content/repositories/orgapachebeam-1103/
> [5] https://github.com/apache/beam/releases/tag/v2.21.0-RC1
> [6] https://github.com/apache/beam/pull/11727
> [7] https://github.com/apache/beam-site/pull/603
> [8] https://github.com/apache/beam/pull/11729
> [9]
> https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=275707202
> [10] https://hub.docker.com/search?q=apache%2Fbeam=image
>
> --
> You received this message because you are subscribed to the Google Groups
> "datapls-team" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to datapls-team+unsubscr...@google.com.
> To view this discussion on the web visit
> https://groups.google.com/a/google.com/d/msgid/datapls-team/CAPNDjO%2BKRLUWDXaeyjheVNMQxFJ%3DeeHUpMUDT_UF8xKFSCDnJA%40mail.gmail.com
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "datapls-eng" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to datapls-eng+unsubscr...@google.com.
> To view this discussion on the web visit
> https://groups.google.com/a/google.com/d/msgid/datapls-eng/CAPNDjO%2BKRLUWDXaeyjheVNMQxFJ%3DeeHUpMUDT_UF8xKFSCDnJA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/a/google.com/d/optout.
>

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

Re: [VOTE] Release 2.21.0, release candidate #1

21 matches

Site Navigation

Mail list logo

Footer information