hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Will cut 1.0.0 RC1 this week (possibly tomorrow)
Date Wed, 21 Jan 2015 18:35:24 GMT
> The unit tests are not in the best shape, but I am trying to see whether that
is a blocker as well.

For the 0.98 series, I will withdraw any release candidate that can't pass
the unit test suite 20 of 20 times. For better or for worse this is our
first line of defense with respect to QA. Actually, I try to test on JDK 6,
7, and usually 8, so that's 60 out of 60, although in a time crunch I might
only look at results on Java 7.

I think for the 1.0.0 release we should apply a similar criteria, and I
would cast a veto vote if the release candidate cannot pass unit tests 20
of 20 times on Java 7, although this is just one vote of course.

On Tue, Jan 20, 2015 at 8:33 PM, Enis Söztutar <enis@apache.org> wrote:

> Just a quick heads up,
> We are approaching a conclusion to the important issue HBASE-12728. There
> are no more blockers to the next RC from what I can see from [1]. So I will
> cut the RC1 for 1.0.0 release shortly after when we commit HBASE-12728.
> The unit tests are not in the best shape, but I am trying to see whether
> that is a blocker as well. In the mean time if you want a particular issue
> to be included, please mark it with fixVersion = 1.0.0 and/or ping me.
> Lastly, for HBASE-12782, I will try to reproduce it from my side as well,
> but we should continue with the RC in the meantime I think. If we find out
> that it is critical to fix, we can sink the RC when we find the root cause
> (or defer to 1.0.1) if needed. Let me know what you think.
> [1]
> https://issues.apache.org/jira/browse/HBASE-12728?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20HBASE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
> Cheers,
> Enis

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message