Jim, Can you provide a git tag and git SHA for the release when you send out the vote so we can check the tarball against the tag.
Thanks! Tom On Thu, Sep 8, 2016 at 1:37 AM, Todd Lipcon <[email protected]> wrote: > - agree with Tim that it would be nice if the tarball extracted into a > directory named apache-impala-incubating-2.7.0 (to match the tarball prefix) > > - A couple places seem to keep a Cloudera copyright/license - eg > common/thrift/beeswax.thrift, FrontEndTestBase.java, etc. (I grepped for > Cloudera and found these). Should probably check over these and fix before > the "real" RC. > > - I tried building using 'buildall.sh' but it failed with 'fatal: Not a git > repository' when trying to do a git clean. Maybe some tweaks need to be > made so that Impala can be built from a tarball? I worked around it using > 'git init' inside my extracted directory. > > - would be nice if the version number didn't have 'cdh5' in it (eg > impala-shell-2.7.0-cdh5-INTERNAL, seems to come from bin/version.info, > bin/save-version.sh, etc). Should probably be '2.7.0-incubating' > > - can't seem to use testdata/bin/run-all.sh to start DFS. I get: > Starting hdfs (Web UI - http://localhost:5070) > Failed to start hdfs-datanode. The end of the log > (/tmp/incubator-impala/testdata/cluster/cdh5/node-2/var/log/hdfs-datanode.out) > is: > Failed to start hdfs-datanode. The end of the log > (/tmp/incubator-impala/testdata/cluster/cdh5/node-3/var/log/hdfs-datanode.out) > is: > Failed to start hdfs-datanode. The end of the log > (/tmp/incubator-impala/testdata/cluster/cdh5/node-1/var/log/hdfs-datanode.out) > is: > > That said, it appears that impalad built OK (with build-all.sh -notests) > > > some nits/suggestions (ok to address in a later release: > - a few mentions of 'Cloudera Impala' in the various pom files > - would be great if buildall.sh could check if there is enough remaining > space on the drive before building. I had 20GB free but still ran out of > space trying to do the default build (had to rebuild with -notests) > - consider setting up a cloudfront distribution in front of the > native-toolchain S3 bucket? It downloads pretty slowly for me > -- related: consider stripping debug info from some of the built deps? eg > Kudu is 500+MB which seems unnecessary for a test dependency. > > > On Wed, Sep 7, 2016 at 5:01 PM, Tim Armstrong <[email protected]> > wrote: > >> I'm in the process of testing this. >> >> One nit that I think we should fix: apache-impala-incubating-2.7. >> 0-rc1.tar.gz >> unpacks to incubator-impala. I think we should stick with the normal >> convention of unpacking to a directory with the same name as the tarball >> (or maybe apache-impala-incubating-2.7.0). >> >> On Wed, Sep 7, 2016 at 2:16 PM, Henry Robinson <[email protected]> wrote: >> >> > Jim, this is great work (by everyone) and the culmination of a ton of >> > effort. Thanks for getting us to this stage! >> > >> > On 7 September 2016 at 14:08, Jim Apple <[email protected]> wrote: >> > >> > > I have put a release candidate, along with checksums and a >> > > cryptographic signature, in >> > > >> > > https://dist.apache.org/repos/dist/dev/incubator/impala/2.7.0/ >> > > >> > > I will be calling for a vote from the PPMC soon. This thread is not >> > > the vote thread. >> > > >> > > That vote will only pass, according to our bylaws, if it has 3 binding >> > > +1 votes and more binding +1 votes than -1 votes. Only the votes of >> > > PPMC members are binding, but anyone may vote. >> > > >> > > If that vote passes, I will ask the Incubator PMC to approve the >> > > release candidate, following the rules on >> > > >> > > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases >> > > >> > > To +1 a release candidate, you will need to verify it. This includes: >> > > >> > > 1. Verifying the signature. You can import my code-signing public key >> > > from gpg using the instructions in >> > > >> > > https://dist.apache.org/repos/dist/dev/incubator/impala/KEYS >> > > >> > > You can also find that key at >> > > >> > > https://pgp.mit.edu/pks/lookup?op=get&search=0x91EE43066850196C >> > > >> > > or >> > > >> > > http://home.apache.org/keys/committer/jbapple >> > > >> > > You will be able to verify the signature by typing >> > > >> > > gpg --verify apache-impala-incubating-2.7.0-rc1.tar.gz.asc >> > > apache-impala-incubating-2.7.0-rc1.tar.gz >> > > >> > > This should happen on a machine you are the sole administrator of and >> > > that you have physical control of: >> > > >> > > http://www.apache.org/dev/release.html#owned-controlled-hardware >> > > >> > > 2. Build and test. You can do the testing on another machine - for >> > > instance, you can upload the RC1 tree to a git repo and point your CI >> > > tool at that repo. >> > > >> > > 3. "verify[ing] that the package meets the requirements of the ASF >> > > policy on releases" >> > > >> > > I suppose that means http://www.apache.org/dev/release.html. I am >> > > asking for clarification on that from our incubating mentors. >> > > >> > > Thank you! >> > > >> > >> > >> > >> > -- >> > Henry Robinson >> > Software Engineer >> > Cloudera >> > 415-994-6679 >> > >> > > > > -- > Todd Lipcon > Software Engineer, Cloudera
