+1 (binding) - downloaded and checked sha - built on an el6 box using devtoolset - ran unit tests, only saw some known flakies - ran a few hundred million rows of single-node YCSB workloads in various configurations (different number of MM threads, different cache sizes) - smoke tested Impala against a single-node cluster. - ran some TPCH queries against a 9-node cluster using Impala on a build not quite identical to the release but quite close (including one cherry-picked in-flight optimization).
I also deployed a build on a 72 node cluster and started YCSB from all hosts (4 threads each) on Tuesday evening (so been running about 2 days). They've collectively inserted 173TB of post-replication data since then. (~50-60B rows I believe). Saw one or two small issues that are known bugs but not regressions (have filed on JIRA). No crashes. Did some basic testing of Spark functionality on the YCSB table. -Todd On Tue, Aug 16, 2016 at 3:04 PM, Misty Stanley-Jones < [email protected]> wrote: > +1 compiled and ran tests on OSX 10.11.6 (El Capitan). Sorry I don't have > time to test elsewhere. > > On Tue, Aug 16, 2016 at 2:01 PM, Dan Burkert <[email protected]> wrote: > > > +1 > > > > Compiled + unit tests run on OS X 10.10.5 > > > > Will pointed out an issue when using the C++ Scan Token API on tables > with > > non-covering range partitioning. Since this is the intersection of a > > rarely used API (scan token creation via C++) with a brand new feature > > (non-covering range partitioning), I think it does not qualify as a > > regression, and shouldn't be a release blocker. A proposed fix is in > > review > > <https://gerrit.cloudera.org/#/c/4007/>, but won't make 0.10 unless we > > sink > > this RC. This issue does not affect executing scan tokens with the C++ > > client, as long as they are created via the Java client (the proposed > > Impala execution model). > > > > - Dan > > > > On Tue, Aug 16, 2016 at 7:46 AM, William Berkeley < > [email protected] > > > > > wrote: > > > > > Compiled + unit tests run on OS X 10.11.6: all pass > > > Compiled + unit tests run on CentOS 7.2: all pass > > > > > > +1 > > > > > > -Will > > > > > > On Tue, Aug 16, 2016 at 3:59 AM, Todd Lipcon <[email protected]> wrote: > > > > > > > Hi, > > > > > > > > The Apache Kudu team is happy to announce the first release candidate > > for > > > > Apache Kudu 0.10.0. > > > > > > > > Based on the release plans previously discussed on the dev@ mailing > > > list, > > > > we anticipate that this will be the last minor release before > reaching > > > > 1.0.0 in September. Notably, this is also Kudu's first release as an > > > Apache > > > > Top-Level Project (TLP). > > > > > > > > The is a source-only release. The artifacts were staged here: > > > > https://dist.apache.org/repos/dist/dev/kudu/0.10.0-RC1/ > > > > > > > > It was built from this tag: > > > > https://git-wip-us.apache.org/repos/asf?p=kudu.git;a=commit;h= > > > > 2b671200388ec15e91df1123740f38b884df7abe > > > > > > > > The release notes can be found here (some links from this document > will > > > > only work when this version is released): > > > > https://github.com/apache/kudu/blob/master/docs/release_ > > > > notes.adoc#rn_0.10.0 > > > > > > > > KEYS file: > > > > http://www.apache.org/dist/incubator/kudu/KEYS > > > > (NOTE: we will relocate this to /dist/kudu/KEYS upon release, but we > > > > currently have no /dist/kudu directory since this is our first > release > > > as a > > > > TLP) > > > > > > > > I'd suggest going through the README, building Kudu, and running the > > > > unit tests. > > > > > > > > Please try the release and vote; the vote will end in 72 hours (on > > > > 8/19/2016 at 1am PDT). > > > > > > > > Thanks, > > > > Todd > > > > > > > > > > -- Todd Lipcon Software Engineer, Cloudera
