Let's call it a -0. :)
On Mon, Dec 11, 2017 at 1:14 PM, Nick Dimiduk wrote:
> On Mon, Dec 11, 2017 at 8:20 AM, Mike Drob wrote:
>
> > Yea, this candidate is fine to promote from my perspective and given the
> > other votes cast. Thanks for putting this
On Mon, Dec 11, 2017 at 8:20 AM, Mike Drob wrote:
> Yea, this candidate is fine to promote from my perspective and given the
> other votes cast. Thanks for putting this together, Nick!
>
Mike,
In that case, would you mind formally upgrading your vote from a -1? I'd
like to
Yea, this candidate is fine to promote from my perspective and given the
other votes cast. Thanks for putting this together, Nick!
On Sun, Dec 10, 2017 at 7:11 PM, Nick Dimiduk wrote:
> At close of the period, this VOTE has received 3x binding +1's, a
> non-binding +1, and
At close of the period, this VOTE has received 3x binding +1's, a
non-binding +1, and a non-binding -1, with no other votes cast.
My understanding is that the issues raised by the non-binding -1 are to be
taken as guidance for subsequent release lines and do not impact the
standing of this
+1
- verified tarballs vs public key on people.apache.org.
- extracted bin tgz:
- inspect structure. look good.
- with jdk1.8.0_65:
- run LoadTestTool against standalone bin tgz with FAST_DIFF block
encoder and ROWCOL blooms. No issues, logs look good.
- poked around webUI. looks
+1
Checked sums and signatures: ok
Ran unit tests: passed
Started standalone cluster and did some basic operations
On Thu, Dec 7, 2017 at 1:14 PM, Andrew Purtell wrote:
> +1
>
> Checked sums and signatures: ok
> Checked compat report: ok
> RAT check passed: ok (7u80)
>
+1
Checked sums and signatures: ok
Checked compat report: ok
RAT check passed: ok (7u80)
Built from source: ok (7u80)
Unit tests pass: ok (8u131)
1M row LTT: ok (8u131)
On Thu, Dec 7, 2017 at 8:40 AM, Nick Dimiduk wrote:
> No one has voted a binding -1 with actionable
No one has voted a binding -1 with actionable changes, so as far as I'm
concerned this RC remains valid. If people need more time, we can extend
this vote.
Thanks,
Nick
On Thu, Dec 7, 2017 at 8:07 AM, Ted Yu wrote:
> Nick:
> Originally you set tomorrow as deadline.
>
> Is
Nick:
Originally you set tomorrow as deadline.
Is there a new RC coming out (w.r.t. Mike's comment) ?
Cheers
On Mon, Dec 4, 2017 at 8:37 PM, Nick Dimiduk wrote:
> Mike:
>
> > Do you plan to make a human-readable set of release notes in addition to
> the list of JIRA
Mike:
> Do you plan to make a human-readable set of release notes in addition to
the list of JIRA issues resolved?
Not as such. For all branch-1.1 releases, I've written up a little
human-friendly summary in the ANNOUNCE email. Basically, expanding on the
list of JIRA tickets I highlight in the
On Mon, Dec 4, 2017 at 11:52 AM, Andrew Purtell wrote:
> > I think this can be fixed by using `git archive` to generate the src tar
> instead of the src assembly.
>
> We could update the make_rc.sh script to create the source tarball in this
> way. Would you be willing to
> I think this can be fixed by using `git archive` to generate the src tar
instead of the src assembly.
We could update the make_rc.sh script to create the source tarball in this
way. Would you be willing to make a patch for that?
For release 1.4.0 and up though I propose we remove
I think I used some shorthand earlier and ambiguously represented my
problem. The issue is that native is missing from the _source_ tarball. I
completely understand why it would be missing from the binary tarball,
maintaining native binaries is a huge hassle and not in our scope, IMO.
However, I
I propose to eject hbase-native-client to GitHub on HBASE-19419
On Mon, Dec 4, 2017 at 11:27 AM, Andrew Purtell wrote:
> hbase-native-client isn't hooked up to the build. We don't have a 'native'
> profile like Hadoop that recurses into native component directories and
>
hbase-native-client isn't hooked up to the build. We don't have a 'native'
profile like Hadoop that recurses into native component directories and
invokes cmake. This won't be available in any RC any RM would generate.
Does one even make sense? Binaries built against what? What do you propose?
On
Thanks for the pointer, Andrew. This worked for me and I was able to start
hbase now and can resume testing.
I didn't mean to imply that Nick needs to create human release notes, but
wanted to know if he had considered it in light of the plan to do so for
1.4.0. I think it's a nice to have, but
I think you need to delete $TMPDIR/hbase-mdrob (or whatever is your username)
before testing the binaries. Looks like you've been testing a later version and
it's left data behind.
We have not produced release notes beyond the JIRA generated ones for prior
releases. We will soon. This is
-1 (non-binding)
general:
+ sign, sums good
src:
- tar missing hbase-native-client (present in tag)
+ can build from source (oracle jdk 1.7.0_80)
bin:
- docs/doap_Hbase.rdf is very out of date (possibly not actually an issue)
- unable to launch using bin/hbase-start.sh (both java 7 and 8), got
+1 (non binding)
Signature, sum: ok
Able to start from bin: ok
Check basic functionalities: ok
LTT with 1M rows: ok
Built from source: ok (8u151)
Rat check: ok
In the logs I saw this line. Source code repository URL looks incorrect.
2017-12-04 10:13:27,028 INFO [main] util.VersionInfo: Source
Thanks for putting this together, Nick!
Do you plan to make a human-readable set of release notes in addition to
the list of JIRA issues resolved?
Mike
On Fri, Dec 1, 2017 at 12:31 AM, Nick Dimiduk wrote:
> I'm happy to announce the first release candidate of HBase 1.1.13
20 matches
Mail list logo