Pardon, that git ref I failed to include below is commit 677ed9ef89 (HEAD
-> branch-1)

On Thu, Apr 11, 2019 at 12:14 PM Andrew Purtell <[email protected]> wrote:

> Thanks for clarifying that this is not a foundation wide policy. It is my
> personal policy to cancel a vote whenever there is a veto, if the reason is
> sound and technical and, presumably, repeatable, at least in the voter's
> environment(s).
>
> Circling back to the main topic, a unit test run of latest branch-1 (git
> ref) completed successfully on my dev host. Based on this result, I would
> release it. I'll include details on my environment below.
>
> It is my theory that the reason some environments observe flaky unit test
> failures and others don't is there are occasional unexpected interactions
> between various units when surefire executes them concurrently, and the
> order in which unit tests are run is dependent on how the underlying OS's
> readdir() call orders directory entries, and this will vary from host to
> host and even from checkout to checkout.
>
> My dev host details
>
> apurtell$ uname -a
> Darwin HOSTNAME 17.7.0 Darwin Kernel Version 17.7.0: Thu Dec 20 21:47:19
> PST 2018; root:xnu-4570.71.22~1/RELEASE_X86_64 x86_64
>
> apurtell$ mvn -v
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T11:41:47-07:00)
> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> Java version: 1.8.0_172, vendor: Azul Systems, Inc., runtime:
> /Users/apurtell/tools/Darwin/jdk/openjdk1.8.0_172_x64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
>
>
> On Thu, Apr 11, 2019 at 11:11 AM Sean Busbey <[email protected]> wrote:
>
>> Just as a point of clarification, -1 votes on releases aren't vetos. ASF
>> policy requires release votes to be majority.
>>
>> As release manager it's your perogative to cancel a vote for whatever
>> reason, but I don't want future RMs thinking they have to fail the vote
>> once there's a -1.
>>
>> On Thu, Apr 11, 2019, 12:18 Andrew Purtell <[email protected]>
>> wrote:
>>
>> > I put back "1.6.0" for TinyLFU backport to branch-1, which I don't think
>> > can happen in the near term because it depends on improvements to
>> precommit
>> > being in place first.
>> >
>> >
>> > On Thu, Apr 11, 2019 at 9:37 AM Andrew Purtell <
>> [email protected]>
>> > wrote:
>> >
>> > > A helpful view for tracking 1.5.0 issues is
>> > > https://issues.apache.org/jira/projects/HBASE/versions/12340316 .
>> > >
>> > > I deleted fixversions "1.5.1" and "1.6.0" and had JIRA rewrite them
>> back
>> > > to "1.5.0" so you won't be confused by JIRA thinking 1.5.0 is in
>> released
>> > > state. All open and pending branch-1 work has the "1.5.0" fix version
>> > > again, until we try again for a release at some future time.
>> > >
>> > >
>> > > On Thu, Apr 11, 2019 at 9:10 AM Andrew Purtell <
>> [email protected]
>> > >
>> > > wrote:
>> > >
>> > >> I have tried to release four 1.5.0 candidates from head of branch-1.
>> > >>
>> > >> Some veto votes were cast for compatibility issues. This was fine.
>> > >>
>> > >> Others are for unit test results that do not reproduce locally for
>> me. I
>> > >> do not have the ability or bandwidth to fix tests which do not fail
>> > >> reliably for me. So let me appeal to the community. If you find a
>> > >> repeatable test failure on branch-1 please file a JIRA and fix it.
>> > >>
>> > >> As things stand now I am pausing any attempts to make more  1.5.0
>> > release
>> > >> candidates until the community steps forward to clean up its code.
>> As an
>> > >> alternative I may start aggressively disabling unit tests which do
>> not
>> > fail
>> > >> for me but have been reported in on candidate vote vetoes. Otherwise
>> it
>> > is
>> > >> impossible to make forward progress.
>> > >>
>> > >> Thank you for your attention.
>>
>

Reply via email to