I was able to run exhaustive tests successfully after committing the entire tarball to a fresh git repository.
On Thu, Sep 8, 2016 at 9:27 AM, Jim Apple <jbap...@cloudera.com> wrote: > Sure, I can tag the tree where I git archive'd my next RC. Just to be > sure I understand you - what exactly do you mean by the "git SHA"? > > On Thu, Sep 8, 2016 at 2:24 AM, Tom White <t...@cloudera.com> wrote: > > 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 <t...@cloudera.com> 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 <tarmstr...@cloudera.com> > >> 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 <he...@cloudera.com> > 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 <jbap...@cloudera.com> > 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 >
