+1

Built and ran all C++ tests on Centos 6.6 in debug and release modes. A
couple failed but, upon retrying, passed.
Ran all Java tests on Centos 6.6 via maven and gradle in release mode. All
passed.

Built and ran all C++ tests on Centos 7.3 in release mode. All passed.
Ran all Java tests on Centos 7.3 via gradle in release mode. A number of
tests failed at first:

   - TestKuduBackup.testSimpleBackupAndRestore and
   TestKuduBackup.testRandomBackupAndRestore (both passed on retry, flakiness
   is tracked as KUDU-2548 <https://issues.apache.org/jira/browse/KUDU-2584>
   )
   - ITClientStressTest.testManyShortClientsGeneratingScanTokens (too many
   open files led to ClassNotFoundException on my shared machine that is
   running Kudu and Impala)
   - TestKuduClient.testGetAuthnToken (passed on retry, some flakiness of
   TestKuduClient tracked in KUDU-2236
   <https://jira.apache.org/jira/browse/KUDU-2236>)
   - TestMasterFailover.testKillLeaderBeforeOpenTable (passed on retry,
   flakiness tracked as KUDU-2592
   <https://jira.apache.org/jira/browse/KUDU-2592>)
   - DefaultSourceTest.testTableScanWithProjectionAndPredicateLong (passed
   on retry, flakiness of DefaultSourceTest is tracked in KUDU-2029
   <https://issues.apache.org/jira/browse/KUDU-2029> and KUDU-2599
   <https://issues.apache.org/jira/browse/KUDU-2599>)
   - DefaultSourceTest.testBasicSparkSQLWithInListPredicate (passed on
   retry, ditto)

The takeaway for me is that while we've been OK about tracking flakiness in
our C++ tests (there exists a flaky test tracking server for them), we
should do a better job at this for Java tests. Within the last release, the
pre-commit gerrit job was updated to retry failed Java tests up to 3x and,
for the sake of pre-commits passing, has costed the introduction of a
number of new flakes. This doesn't seem release-blocking, but we should be
mindful to address this moving forward.

On Tue, Oct 16, 2018 at 2:47 AM Attila Bukor <[email protected]> wrote:

> Hi Devs,
>
> As suggested on the RC1 vote thread, I've included the complete fix for
> KUDU-2463 and created a new release candidate for Apache Kudu 1.8.0.
>
> Apache Kudu 1.8.0 is a minor release that offers many improvements and
> fixes
> since the prior release.
>
> The is a source-only release. The artifacts have been staged here:
> https://dist.apache.org/repos/dist/dev/kudu/1.8.0-RC2/
>
> Java convenience binaries in the form of a Maven repository are staged
> here:
> https://repository.apache.org/content/repositories/orgapachekudu-1027
>
> It is tagged in Git as 1.8.0-RC2 and the corresponding hash is the
> following:
>
> https://git-wip-us.apache.org/repos/asf?p=kudu.git;a=commit;h=cbbf7b580c4ab4fdf6621e4ee5ab1ddc5f03cb4e
>
> The release notes can be found here:
> https://github.com/apache/kudu/blob/1.8.0-RC2/docs/release_notes.adoc
>
> The KEYS file to verify the artifact signatures can be found here:
> https://dist.apache.org/repos/dist/release/kudu/KEYS
>
> I'd suggest going through the README and the release notes, building
> Kudu, and running the unit tests. Testing out the Maven repo would also
> be appreciated.
>
> The vote will run at least until Friday, October 19th at 11:59 AM CEST.
>
> Thank you,
> Attila
>

Reply via email to