impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Armstrong <tarmstr...@cloudera.com>
Subject Re: Prepare to vote on release candidate 1
Date Fri, 09 Sep 2016 15:39:51 GMT
One thing is to make sure that you don't have any environment variables set
pointing to a different directory. E.g. I have IMPALA_HOME in my
environment.

On Fri, Sep 9, 2016 at 2:09 AM, Lars Volker <lv@cloudera.com> wrote:

> I unpacked the tarball, added all files to a fresh git repo and ran
> buildall.sh. It terminated with the following error:
>
> CMake Error at be/src/util/CMakeLists.txt:89 (add_library):
>   Cannot find source file:
>
>     /home/lv/asf/incubator-impala/be/src/thirdparty/squeasel/squeasel.c
>
> Can we add the steps you used to build and run the tests to the README
> file, so it's easier to validate?
>
> On Fri, Sep 9, 2016 at 11:04 AM, Tom White <tom@cloudera.com> wrote:
>
> > On Thu, Sep 8, 2016 at 5:27 PM, Jim Apple <jbapple@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"?
> >
> > I just mean git hash.
> >
> > >
> > > On Thu, Sep 8, 2016 at 2:24 AM, Tom White <tom@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 <todd@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 <
> tarmstrong@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 <henry@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 <jbapple@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.htm
> > l#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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message