Re: Impala 3.x (and 2.x)

We could commit first and then GVO -- that way if a commit broke something (in a reproducible way), we would at least know which commit did it. In this proposal, we don't have to wait for GVO N to finish before committing patch N+1. This is a sort of fast-path-slow-path idea, but fixing the slow

Re: Impala 3.x (and 2.x)

If we do the GVO route, would folks be comfortable with Jenkins taking care of promoting cherrypicks to a staging branch (say, 2.x-staging), and then Jenkins, again, running the tests and pushing that through to gerrit/2.x? (As always, the push to the official ASF repo is only done by a human,

Re: Impala 3.x (and 2.x)

An update here! I'm pretty close to pushing the first master-only change (the very exciting 1-liner at https://gerrit.cloudera.org/#/c/9044/ that bumps versions). After that, I'll be cherrypicking things into 2.x. We need a policy, I think, on reviewing these cherry-picks. The most heavy-weight

Re:Re:Re: Re: Re: Cancellation logic in HdfsScanners

Hi Tim, I believe it's a bug and find out a way to reproduce it. Have filed a JIRA: https://issues.apache.org/jira/browse/IMPALA-6423 At 2018-01-17 08:53:44, "Quanlong Huang" wrote: >Thanks, Tim! Let me try to reproduce this scenario on existing scanners. I'll >file a