+1 Compiled + ran unit tests on dist_test, one test failed - although it wasn’t consistently repro’ble, and didn’t appear to be a regression. I may triage that as bug after some basic troubleshooting.
Thanks, Dinesh. > On Aug 18, 2016, at 5:48 PM, Todd Lipcon <[email protected]> wrote: > > +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
