The upgrade is worth for security reasons and to catch the gRPC improvements so really nice that this is happening.
However I am not clear if we are mixing two things here. (1) The release of the vendored versions and (2) the upgrade of it into Beam. I think those should be separate (obviously knowing that the latter is more complex). My point is the vote should be ONLY about releasing the vendored dependencies and we should not mix it with what otherwise would be a JIRA issue for the dependency upgrade. (This was the case in the previous release of the vendored deps) An Apache release is usually validated from a .tar.gz with the source code checkout of the associated commit that should produce the artifacts, and I don't see any source code staged for validation in the links. All these points come from the fact that we have not documented the process of verification and in general of release of the vendored dependencies, so probably it is worth to do this and add it to the release guide [1] (or as an independent document) so we can do the validation eagerly. [1] https://beam.apache.org/contribute/release-guide/ On Mon, Jun 24, 2019 at 6:02 PM Lukasz Cwik <lc...@google.com> wrote: > > Pinging for PMC to validate & vote. > > On Thu, Jun 20, 2019 at 3:52 PM Ahmet Altay <al...@google.com> wrote: >> >> +1 verified signatures and hashes. >> >> Thank you Luke. >> >> On Thu, Jun 20, 2019 at 12:27 PM Lukasz Cwik <lc...@google.com> wrote: >>> >>> We should verify the signatures of the artifacts. >>> >>> Otherwise, there is little risk in releasing these artifacts because no one >>> consumes them yet. PR/8899[1] updates Apache Beam to start using them and >>> will go through the regular precommit/postcommit tests. >>> >>> If you want to perform additional validation you can: >>> * clone the PR and run any tests that you may want after fetching the >>> artifacts and placing them in your local maven repo >>> * download the artifacts and manually validate the classes only appear in >>> the org.apache.beam.vendor namespace with the appropriate package prefix. >>> Note that there is a unit test that does this as part of the publishing >>> process[2]. >>> >>> This thread[3] is an example of previous release of vendored artifacts. >>> >>> 1: https://github.com/apache/beam/pull/8899 >>> 2: >>> https://github.com/apache/beam/blob/c775eda2df6457a784a1945d16cf781abb453d5f/buildSrc/src/main/groovy/org/apache/beam/gradle/VendorJavaPlugin.groovy#L127 >>> 3: >>> https://lists.apache.org/thread.html/9efb2aeab102e41367bf6b1f274d3ee5990024afd934392a339c4d00@%3Cdev.beam.apache.org%3E >>> >>> On Thu, Jun 20, 2019 at 11:20 AM Ahmet Altay <al...@google.com> wrote: >>>> >>>> What is the best way to validate this? >>>> >>>> On Thu, Jun 20, 2019 at 9:51 AM Lukasz Cwik <lc...@google.com> wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> Please review the release of the following artifacts that we vendor: >>>>> beam-vendor-guava-26_0-jre >>>>> beam-vendor-grpc-1_21_0 >>>>> >>>>> Please vote 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: >>>>> * all artifacts to be deployed to the Maven Central Repository [1], >>>>> * commit hash "996b4c3733545aaa3b93fd35296a391126026a1c" [2], >>>>> * which is signed with the key with fingerprint >>>>> EAD5DE293F4A03DD2E77565589E68A56E371CCA2 [3], >>>>> >>>>> The vote will be open for at least 72 hours. It is adopted by majority >>>>> approval, with at least 3 PMC affirmative votes. >>>>> >>>>> Note I have no intention to get this into the current 2.14 release that >>>>> is being worked on and will have the version update go out with the next >>>>> release. >>>>> >>>>> Thanks, >>>>> Luke >>>>> >>>>> [1] https://repository.apache.org/content/repositories/orgapachebeam-1074/ >>>>> [2] https://github.com/apache/beam/pull/8899 >>>>> [3] https://dist.apache.org/repos/dist/release/beam/KEYS >>>>>
