Kudu server binary test jars for 1.9.0

Hi devs, For the 1.9.0 release, we (Grant Henke, Brian McDevitt, and I) implemented the capability to start a Kudu minicluster from a JVM environment without having to first build Kudu locally (work tracked as KUDU-2411 ). This was made possible by u

Re: Kudu server binary test jars for 1.9.0

Thank you for progressing all this Mike (and others). I will endeavour to test this soon and replace the Beam unit tests with this - I've been sidelined a bit recently with other tasks but getting back into Beam development again. On Tue, Mar 5, 2019 at 9:16 AM Mike Percy wrote: > Hi devs, >

Re: Regarding index skip scan in kudu

Hi Mike, Thanks for the speedy reply. I would like to help with this. How do I get started on this? Regards, Shanmuga On Mon, Mar 4, 2019 at 11:59 AM Mike Percy wrote: > Hi Shanmuga, > Unfortunately the original author's internship ended last summer and > nobody has taken the time to complete

Re: Kudu server binary test jars for 1.9.0

+1 on this plan. Thanks for wrapping this up Mike! I ran the test locally on my Mac (10.14.2) with no issues. I also ran the tests in a docker image for the following operating systems: - centos:6 - centos:7 - debian:jessie - debian:stretch - ubuntu:trusty - ubuntu:xenial -

Re: Kudu server binary test jars for 1.9.0

I ran your example on macOS High Sierra 10.13.6 and on CentOS 7.3, only issue I ran into was because of the Maven version. I'll let this sit for the day or so in case people want to chyme in, and then proceed with the release. Thanks for pushing this through! On Tue, Mar 5, 2019 at 8:44 AM Grant

Re: Kudu backport policy

On Wed, Feb 27, 2019 at 3:33 PM Adar Lieber-Dembo wrote: > What sorts of patches merit backporting? Off the top of my head: > - Fixes that keep CI working (e.g. pinning of unpinned Python > dependencies that break). > +1, I am even in favor of skipping code review in this case if another committe

Re: Kudu backport policy

> > only backport to branches where we expect possible maintenance releases. +1 on this, and on defining a "default" maintenance branch window of one minor release. If for some reason we did need to go further back, we could piece together some fixes from the tips of the more recent .x branches.