SQL layer over Accumulo?

[James Taylor]

Hello,
Would there be any interest in developing a SQL-layer on top of Accumulo?
I'm part of the Apache Phoenix project and we've built a similar system on
top of HBase. I wanted to see if there'd be interest on your end at working
with us to generalizing our client and provide in a server that would do
Accumulo-specific push down in support of a SQL layer. I suspect there's
enough similarity between HBase and Accumulo that this would be feasible.
Thanks,
James

Re: CHANGES file for 1.6.0-RC5

[Mike Drob]

+1 b
+0 c


On Mon, Apr 28, 2014 at 10:02 PM, John Vines  wrote:

> +1 b
> +0 c
>
>
> On Mon, Apr 28, 2014 at 9:48 PM, Bill Havanki  >wrote:
>
> > b, and prefer c over d but not overly so
> >
> >
> > On Mon, Apr 28, 2014 at 7:45 PM, Sean Busbey 
> wrote:
> >
> > > B and C (though I would like subtasks to be listed last)
> > >
> > >
> > >
> > > On Mon, Apr 28, 2014 at 6:41 PM, Josh Elser 
> > wrote:
> > >
> > > > b, please.
> > > >
> > > > I would lean towards C over D as I think that's what we've done
> > > > previously, but I do not have strong feelings either way.
> > > >
> > > >
> > > > On 4/28/14, 7:29 PM, Christopher wrote:
> > > >
> > > >> All,
> > > >>
> > > >> Mike had an objection to the inclusion of 1.4.0 and 1.5.0 changes in
> > > >> the CHANGES file for 1.6.0.
> > > >> That objection was based on his understanding of a previous thread.
> > > >> I'm not sure there was ever consensus on what to do, and I had a
> > > >> different understanding of the results of that thread. I'd like to
> > > >> resolve this with extreme haste.
> > > >>
> > > >> Background:
> > > >>
> > > >> The current 1.6.0-RC CHANGES have included 1.4.0, and 1.5.0, and
> > > >> 1.6.0, with the expectation that 1.6.1 would contain all those, plus
> > > >> 1.6.1, and 1.6.2 would contain all those, plus 1.6.2 changes, etc.
> > > >> This fits with how we are currently labeling things in JIRA.
> > > >> However, we could just as easily drop 1.4.0 and 1.5.0 changes from
> the
> > > >> file, and it still matches what we're doing in JIRA. This is what
> > > >> happened with 1.5.0.
> > > >>
> > > >> So, which do we do? a or b:
> > > >>
> > > >> a) include 1.4.0, 1.5.0
> > > >> b) do not include 1.4.0, 1.5.0
> > > >>
> > > >> Additionally, should we (c or d):
> > > >>
> > > >> c) include sub-tasks
> > > >> d) do not include sub-tasks
> > > >>
> > > >> I'll update the CHANGES for RC5 according to the majority view from
> > > >> this discussion at the time I prep RC5 (probably tomorrow morning).
> > > >> I lean towards (b) and (d), but don't feel very strongly. I just
> don't
> > > >> want to see a released blocked on this file.
> > > >>
> > > >> --
> > > >> Christopher L Tubbs II
> > > >> http://gravatar.com/ctubbsii
> > > >>
> > > >>
> > >
> > >
> > > --
> > > Sean
> > >
> >
> >
> >
> > --
> > // Bill Havanki
> > // Solutions Architect, Cloudera Govt Solutions
> > // 443.686.9283
> >
>

Re: CHANGES file for 1.6.0-RC5

[John Vines]

+1 b
+0 c


On Mon, Apr 28, 2014 at 9:48 PM, Bill Havanki wrote:

> b, and prefer c over d but not overly so
>
>
> On Mon, Apr 28, 2014 at 7:45 PM, Sean Busbey  wrote:
>
> > B and C (though I would like subtasks to be listed last)
> >
> >
> >
> > On Mon, Apr 28, 2014 at 6:41 PM, Josh Elser 
> wrote:
> >
> > > b, please.
> > >
> > > I would lean towards C over D as I think that's what we've done
> > > previously, but I do not have strong feelings either way.
> > >
> > >
> > > On 4/28/14, 7:29 PM, Christopher wrote:
> > >
> > >> All,
> > >>
> > >> Mike had an objection to the inclusion of 1.4.0 and 1.5.0 changes in
> > >> the CHANGES file for 1.6.0.
> > >> That objection was based on his understanding of a previous thread.
> > >> I'm not sure there was ever consensus on what to do, and I had a
> > >> different understanding of the results of that thread. I'd like to
> > >> resolve this with extreme haste.
> > >>
> > >> Background:
> > >>
> > >> The current 1.6.0-RC CHANGES have included 1.4.0, and 1.5.0, and
> > >> 1.6.0, with the expectation that 1.6.1 would contain all those, plus
> > >> 1.6.1, and 1.6.2 would contain all those, plus 1.6.2 changes, etc.
> > >> This fits with how we are currently labeling things in JIRA.
> > >> However, we could just as easily drop 1.4.0 and 1.5.0 changes from the
> > >> file, and it still matches what we're doing in JIRA. This is what
> > >> happened with 1.5.0.
> > >>
> > >> So, which do we do? a or b:
> > >>
> > >> a) include 1.4.0, 1.5.0
> > >> b) do not include 1.4.0, 1.5.0
> > >>
> > >> Additionally, should we (c or d):
> > >>
> > >> c) include sub-tasks
> > >> d) do not include sub-tasks
> > >>
> > >> I'll update the CHANGES for RC5 according to the majority view from
> > >> this discussion at the time I prep RC5 (probably tomorrow morning).
> > >> I lean towards (b) and (d), but don't feel very strongly. I just don't
> > >> want to see a released blocked on this file.
> > >>
> > >> --
> > >> Christopher L Tubbs II
> > >> http://gravatar.com/ctubbsii
> > >>
> > >>
> >
> >
> > --
> > Sean
> >
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283
>

Re: CHANGES file for 1.6.0-RC5

[Bill Havanki]

b, and prefer c over d but not overly so


On Mon, Apr 28, 2014 at 7:45 PM, Sean Busbey  wrote:

> B and C (though I would like subtasks to be listed last)
>
>
>
> On Mon, Apr 28, 2014 at 6:41 PM, Josh Elser  wrote:
>
> > b, please.
> >
> > I would lean towards C over D as I think that's what we've done
> > previously, but I do not have strong feelings either way.
> >
> >
> > On 4/28/14, 7:29 PM, Christopher wrote:
> >
> >> All,
> >>
> >> Mike had an objection to the inclusion of 1.4.0 and 1.5.0 changes in
> >> the CHANGES file for 1.6.0.
> >> That objection was based on his understanding of a previous thread.
> >> I'm not sure there was ever consensus on what to do, and I had a
> >> different understanding of the results of that thread. I'd like to
> >> resolve this with extreme haste.
> >>
> >> Background:
> >>
> >> The current 1.6.0-RC CHANGES have included 1.4.0, and 1.5.0, and
> >> 1.6.0, with the expectation that 1.6.1 would contain all those, plus
> >> 1.6.1, and 1.6.2 would contain all those, plus 1.6.2 changes, etc.
> >> This fits with how we are currently labeling things in JIRA.
> >> However, we could just as easily drop 1.4.0 and 1.5.0 changes from the
> >> file, and it still matches what we're doing in JIRA. This is what
> >> happened with 1.5.0.
> >>
> >> So, which do we do? a or b:
> >>
> >> a) include 1.4.0, 1.5.0
> >> b) do not include 1.4.0, 1.5.0
> >>
> >> Additionally, should we (c or d):
> >>
> >> c) include sub-tasks
> >> d) do not include sub-tasks
> >>
> >> I'll update the CHANGES for RC5 according to the majority view from
> >> this discussion at the time I prep RC5 (probably tomorrow morning).
> >> I lean towards (b) and (d), but don't feel very strongly. I just don't
> >> want to see a released blocked on this file.
> >>
> >> --
> >> Christopher L Tubbs II
> >> http://gravatar.com/ctubbsii
> >>
> >>
>
>
> --
> Sean
>



-- 
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283

Re: CHANGES file for 1.6.0-RC5

[Sean Busbey]

B and C (though I would like subtasks to be listed last)



On Mon, Apr 28, 2014 at 6:41 PM, Josh Elser  wrote:

> b, please.
>
> I would lean towards C over D as I think that's what we've done
> previously, but I do not have strong feelings either way.
>
>
> On 4/28/14, 7:29 PM, Christopher wrote:
>
>> All,
>>
>> Mike had an objection to the inclusion of 1.4.0 and 1.5.0 changes in
>> the CHANGES file for 1.6.0.
>> That objection was based on his understanding of a previous thread.
>> I'm not sure there was ever consensus on what to do, and I had a
>> different understanding of the results of that thread. I'd like to
>> resolve this with extreme haste.
>>
>> Background:
>>
>> The current 1.6.0-RC CHANGES have included 1.4.0, and 1.5.0, and
>> 1.6.0, with the expectation that 1.6.1 would contain all those, plus
>> 1.6.1, and 1.6.2 would contain all those, plus 1.6.2 changes, etc.
>> This fits with how we are currently labeling things in JIRA.
>> However, we could just as easily drop 1.4.0 and 1.5.0 changes from the
>> file, and it still matches what we're doing in JIRA. This is what
>> happened with 1.5.0.
>>
>> So, which do we do? a or b:
>>
>> a) include 1.4.0, 1.5.0
>> b) do not include 1.4.0, 1.5.0
>>
>> Additionally, should we (c or d):
>>
>> c) include sub-tasks
>> d) do not include sub-tasks
>>
>> I'll update the CHANGES for RC5 according to the majority view from
>> this discussion at the time I prep RC5 (probably tomorrow morning).
>> I lean towards (b) and (d), but don't feel very strongly. I just don't
>> want to see a released blocked on this file.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>


-- 
Sean

Re: CHANGES file for 1.6.0-RC5

[Josh Elser]

b, please.

I would lean towards C over D as I think that's what we've done 
previously, but I do not have strong feelings either way.


On 4/28/14, 7:29 PM, Christopher wrote:

All,

Mike had an objection to the inclusion of 1.4.0 and 1.5.0 changes in
the CHANGES file for 1.6.0.
That objection was based on his understanding of a previous thread.
I'm not sure there was ever consensus on what to do, and I had a
different understanding of the results of that thread. I'd like to
resolve this with extreme haste.

Background:

The current 1.6.0-RC CHANGES have included 1.4.0, and 1.5.0, and
1.6.0, with the expectation that 1.6.1 would contain all those, plus
1.6.1, and 1.6.2 would contain all those, plus 1.6.2 changes, etc.
This fits with how we are currently labeling things in JIRA.
However, we could just as easily drop 1.4.0 and 1.5.0 changes from the
file, and it still matches what we're doing in JIRA. This is what
happened with 1.5.0.

So, which do we do? a or b:

a) include 1.4.0, 1.5.0
b) do not include 1.4.0, 1.5.0

Additionally, should we (c or d):

c) include sub-tasks
d) do not include sub-tasks

I'll update the CHANGES for RC5 according to the majority view from
this discussion at the time I prep RC5 (probably tomorrow morning).
I lean towards (b) and (d), but don't feel very strongly. I just don't
want to see a released blocked on this file.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

CHANGES file for 1.6.0-RC5

[Christopher]

All,

Mike had an objection to the inclusion of 1.4.0 and 1.5.0 changes in
the CHANGES file for 1.6.0.
That objection was based on his understanding of a previous thread.
I'm not sure there was ever consensus on what to do, and I had a
different understanding of the results of that thread. I'd like to
resolve this with extreme haste.

Background:

The current 1.6.0-RC CHANGES have included 1.4.0, and 1.5.0, and
1.6.0, with the expectation that 1.6.1 would contain all those, plus
1.6.1, and 1.6.2 would contain all those, plus 1.6.2 changes, etc.
This fits with how we are currently labeling things in JIRA.
However, we could just as easily drop 1.4.0 and 1.5.0 changes from the
file, and it still matches what we're doing in JIRA. This is what
happened with 1.5.0.

So, which do we do? a or b:

a) include 1.4.0, 1.5.0
b) do not include 1.4.0, 1.5.0

Additionally, should we (c or d):

c) include sub-tasks
d) do not include sub-tasks

I'll update the CHANGES for RC5 according to the majority view from
this discussion at the time I prep RC5 (probably tomorrow morning).
I lean towards (b) and (d), but don't feel very strongly. I just don't
want to see a released blocked on this file.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

Re: [VOTE] Accumulo 1.6.0-RC4

[Keith Turner]

-1 because of issue w/ license files.


Opened ACCUMULO-2749.  I am not sure this should hold up 1.6.0 unless we
can figure out what the problem is in short order.


On Fri, Apr 25, 2014 at 8:35 PM, Christopher  wrote:

> Accumulo Developers,
>
> Please consider the following candidate for Accumulo 1.6.0.
>
> Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
> Branch: 1.6.0-RC4
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
> Source:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
> Binary:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
> (Append ".sha1", ".md5" or ".asc" to download the signature/hash for a
> given artifact.)
>
> All artifacts were built and staged with:
> mvn release:prepare && mvn release:perform
>
> Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
>
> Release notes (in progress):
> http://accumulo.apache.org/release_notes/1.6.0
>
> Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):
>
> https://issues.apache.org/jira/browse/ACCUMULO-1219
> https://issues.apache.org/jira/browse/ACCUMULO-2523
> https://issues.apache.org/jira/browse/ACCUMULO-2569
> https://issues.apache.org/jira/browse/ACCUMULO-2654
> https://issues.apache.org/jira/browse/ACCUMULO-2707
> https://issues.apache.org/jira/browse/ACCUMULO-2713
> https://issues.apache.org/jira/browse/ACCUMULO-2714
> https://issues.apache.org/jira/browse/ACCUMULO-2715
> https://issues.apache.org/jira/browse/ACCUMULO-2716
> https://issues.apache.org/jira/browse/ACCUMULO-2717
> https://issues.apache.org/jira/browse/ACCUMULO-2718
> https://issues.apache.org/jira/browse/ACCUMULO-2720
> https://issues.apache.org/jira/browse/ACCUMULO-2723
> https://issues.apache.org/jira/browse/ACCUMULO-2726
> https://issues.apache.org/jira/browse/ACCUMULO-2728
> https://issues.apache.org/jira/browse/ACCUMULO-2729
> https://issues.apache.org/jira/browse/ACCUMULO-2733
> https://issues.apache.org/jira/browse/ACCUMULO-2734
>
> This vote will remain open for 72 hours (3 days), until Tue, 2014
> April 28 01:00 UTC.
> (That's 9pm EDT on Monday.)
>
> [ ] +1 - I have verified and accept...
> [ ] +0 - I have reservations, but not strong enough to vote against...
> [ ] -1 - Because..., I do not accept...
> ... these artifacts as the 1.6.0 release of Apache Accumulo.
>
> Thanks.
>
> P.S. Hint: download the whole staging repo with
> wget -erobots=off -r -l inf -np -nH
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/
> # note the trailing slash is needed
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>

Re: [VOTE] Accumulo 1.6.0-RC4

[Keith Turner]

There was a discussion about CHANGES.  I am not sure there could truly be
consensus w/o a vote on that particular subject.  I don't think its
something that should hold up 1.6.0




On Mon, Apr 28, 2014 at 5:19 PM, Christopher  wrote:

> Going to vote +0 myself, for the license issues Mike points out.
> I don't have an opinion about the CHANGES file, but I'd like consensus
> before changing it again.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob  wrote:
> > -1
> >
> > The good:
> >
> > * Verified all signatures and checksums.
> > * Ran continuous ingest with binary artifact + custom built native maps.
> >
> >
> > The issues, but not enough to vote against:
> >
> > * Encountered ACCUMULO-2741.
> > * Encountered ACCUMULO-2742.
> > * Source artifact missing .gitignore
> > ** This has been discussed, and I'm voting for precedent here. We can
> agree
> > to disagree, and if this vote passes then a new precedent will have been
> > set.
> >
> >
> > The bad:
> >
> > * CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD)
> > ** Past discussion here: http://markmail.org/message/ulvovup36uaa2cav
> > ** It seems like we agreed to only include changes from the current major
> > release line, but that is not 100% clear.
> >
> > * Missing licence headers:
> > ** README
> > ** conf/examples/crypto/readme.txt
> > ** test/compat/japi-compliance/README
> > ** test/system/continuous/ScaleTest.odp
> > **
> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
> >
> > **
> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
> >
> > **
> > docs/src/main/latex/common/state_diagrams/tablet_states.odg
> >
> > ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
> >
> > On Fri, Apr 25, 2014 at 8:35 PM, Christopher 
> wrote:
> >
> >> Accumulo Developers,
> >>
> >> Please consider the following candidate for Accumulo 1.6.0.
> >>
> >> Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
> >> Branch: 1.6.0-RC4
> >>
> >> Staging repo:
> >>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
> >> Source:
> >>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
> >> Binary:
> >>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
> >> (Append ".sha1", ".md5" or ".asc" to download the signature/hash for a
> >> given artifact.)
> >>
> >> All artifacts were built and staged with:
> >> mvn release:prepare && mvn release:perform
> >>
> >> Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
> >>
> >> Release notes (in progress):
> >> http://accumulo.apache.org/release_notes/1.6.0
> >>
> >> Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):
> >>
> >> https://issues.apache.org/jira/browse/ACCUMULO-1219
> >> https://issues.apache.org/jira/browse/ACCUMULO-2523
> >> https://issues.apache.org/jira/browse/ACCUMULO-2569
> >> https://issues.apache.org/jira/browse/ACCUMULO-2654
> >> https://issues.apache.org/jira/browse/ACCUMULO-2707
> >> https://issues.apache.org/jira/browse/ACCUMULO-2713
> >> https://issues.apache.org/jira/browse/ACCUMULO-2714
> >> https://issues.apache.org/jira/browse/ACCUMULO-2715
> >> https://issues.apache.org/jira/browse/ACCUMULO-2716
> >> https://issues.apache.org/jira/browse/ACCUMULO-2717
> >> https://issues.apache.org/jira/browse/ACCUMULO-2718
> >> https://issues.apache.org/jira/browse/ACCUMULO-2720
> >> https://issues.apache.org/jira/browse/ACCUMULO-2723
> >> https://issues.apache.org/jira/browse/ACCUMULO-2726
> >> https://issues.apache.org/jira/browse/ACCUMULO-2728
> >> https://issues.apache.org/jira/browse/ACCUMULO-2729
> >> https://issues.apache.org/jira/browse/ACCUMULO-2733
> >> https://issues.apache.org/jira/browse/ACCUMULO-2734
> >>
> >> This vote will remain open for 72 hours (3 days), until Tue, 2014
> >> April 28 01:00 UTC.
> >> (That's 9pm EDT on Monday.)
> >>
> >> [ ] +1 - I have verified and accept...
> >> [ ] +0 - I have reservations, but not strong enough to vote against...
> >> [ ] -1 - Because..., I do not accept...
> >> ... these artifacts as the 1.6.0 release of Apache Accumulo.
> >>
> >> Thanks.
> >>
> >> P.S. Hint: download the whole staging repo with
> >> wget -erobots=off -r -l inf -np -nH
> >>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/
> >> # note the trailing slash is needed
> >>
> >> --
> >> Christopher L Tubbs II
> >> http://gravatar.com/ctubbsii
> >>
>

Re: Review Request 20790: ACCUMULO-2742 offset history command by one

[Christopher Tubbs]

> On April 28, 2014, 6:29 p.m., Christopher Tubbs wrote:
> > Ship It!

Actually... before you ship it, it'd be nice if there were a small comment 
explaining the assume usage in the event expansion test... just to explain why 
it doesn't work under some Eclipse environments.


- Christopher


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20790/#review41644
---


On April 28, 2014, 6:11 p.m., Mike Drob wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20790/
> ---
> 
> (Updated April 28, 2014, 6:11 p.m.)
> 
> 
> Review request for accumulo.
> 
> 
> Bugs: ACCUMULO-2742
> https://issues.apache.org/jira/browse/ACCUMULO-2742
> 
> 
> Repository: accumulo
> 
> 
> Description
> ---
> 
> ACCUMULO-2742 offset history command by one
> 
> The history entries returned by the history command are 0-indexed,
> while the history expansion is 1-indexed. We need to offset the index
> when we print it so that users can accurately use event expansion.
> 
> 
> Diffs
> -
> 
>   
> core/src/main/java/org/apache/accumulo/core/util/shell/commands/HistoryCommand.java
>  9531d903aca834ab3b70650824023061e7e788d9 
>   
> core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/20790/diff/
> 
> 
> Testing
> ---
> 
> New unit test. Verified on cluster deployment.
> 
> 
> Thanks,
> 
> Mike Drob
> 
>

Re: Review Request 20790: ACCUMULO-2742 offset history command by one

[Christopher Tubbs]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20790/#review41644
---

Ship it!


Ship It!

- Christopher Tubbs


On April 28, 2014, 6:11 p.m., Mike Drob wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20790/
> ---
> 
> (Updated April 28, 2014, 6:11 p.m.)
> 
> 
> Review request for accumulo.
> 
> 
> Bugs: ACCUMULO-2742
> https://issues.apache.org/jira/browse/ACCUMULO-2742
> 
> 
> Repository: accumulo
> 
> 
> Description
> ---
> 
> ACCUMULO-2742 offset history command by one
> 
> The history entries returned by the history command are 0-indexed,
> while the history expansion is 1-indexed. We need to offset the index
> when we print it so that users can accurately use event expansion.
> 
> 
> Diffs
> -
> 
>   
> core/src/main/java/org/apache/accumulo/core/util/shell/commands/HistoryCommand.java
>  9531d903aca834ab3b70650824023061e7e788d9 
>   
> core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/20790/diff/
> 
> 
> Testing
> ---
> 
> New unit test. Verified on cluster deployment.
> 
> 
> Thanks,
> 
> Mike Drob
> 
>

Re: Review Request 20790: ACCUMULO-2742 offset history command by one

[Mike Drob]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20790/
---

(Updated April 28, 2014, 10:11 p.m.)


Review request for accumulo.


Changes
---

Verify that we are running in a supported terminal before using features.


Bugs: ACCUMULO-2742
https://issues.apache.org/jira/browse/ACCUMULO-2742


Repository: accumulo


Description
---

ACCUMULO-2742 offset history command by one

The history entries returned by the history command are 0-indexed,
while the history expansion is 1-indexed. We need to offset the index
when we print it so that users can accurately use event expansion.


Diffs (updated)
-

  
core/src/main/java/org/apache/accumulo/core/util/shell/commands/HistoryCommand.java
 9531d903aca834ab3b70650824023061e7e788d9 
  
core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java
 PRE-CREATION 

Diff: https://reviews.apache.org/r/20790/diff/


Testing
---

New unit test. Verified on cluster deployment.


Thanks,

Mike Drob

Re: [VOTE] Accumulo 1.6.0-RC4

[Sean Busbey]

+1

* Signatures and hashes validated.
* Source artifact matches given commit, modulo previously mentioned
.gitignore file.
* I agree that previous tests needn't be invalidated by changes introduced
in this RC
* Did one last run through the ITs with each of the hadoop profiles
* I am aware of concerns about ACCUMULO-2745 and the recent run of last
minute blockers.

-Sean

On Fri, Apr 25, 2014 at 7:35 PM, Christopher  wrote:

> Accumulo Developers,
>
> Please consider the following candidate for Accumulo 1.6.0.
>
> Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
> Branch: 1.6.0-RC4
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
> Source:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
> Binary:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
> (Append ".sha1", ".md5" or ".asc" to download the signature/hash for a
> given artifact.)
>
> All artifacts were built and staged with:
> mvn release:prepare && mvn release:perform
>
> Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
>
> Release notes (in progress):
> http://accumulo.apache.org/release_notes/1.6.0
>
> Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):
>
> https://issues.apache.org/jira/browse/ACCUMULO-1219
> https://issues.apache.org/jira/browse/ACCUMULO-2523
> https://issues.apache.org/jira/browse/ACCUMULO-2569
> https://issues.apache.org/jira/browse/ACCUMULO-2654
> https://issues.apache.org/jira/browse/ACCUMULO-2707
> https://issues.apache.org/jira/browse/ACCUMULO-2713
> https://issues.apache.org/jira/browse/ACCUMULO-2714
> https://issues.apache.org/jira/browse/ACCUMULO-2715
> https://issues.apache.org/jira/browse/ACCUMULO-2716
> https://issues.apache.org/jira/browse/ACCUMULO-2717
> https://issues.apache.org/jira/browse/ACCUMULO-2718
> https://issues.apache.org/jira/browse/ACCUMULO-2720
> https://issues.apache.org/jira/browse/ACCUMULO-2723
> https://issues.apache.org/jira/browse/ACCUMULO-2726
> https://issues.apache.org/jira/browse/ACCUMULO-2728
> https://issues.apache.org/jira/browse/ACCUMULO-2729
> https://issues.apache.org/jira/browse/ACCUMULO-2733
> https://issues.apache.org/jira/browse/ACCUMULO-2734
>
> This vote will remain open for 72 hours (3 days), until Tue, 2014
> April 28 01:00 UTC.
> (That's 9pm EDT on Monday.)
>
> [ ] +1 - I have verified and accept...
> [ ] +0 - I have reservations, but not strong enough to vote against...
> [ ] -1 - Because..., I do not accept...
> ... these artifacts as the 1.6.0 release of Apache Accumulo.
>
> Thanks.
>
> P.S. Hint: download the whole staging repo with
> wget -erobots=off -r -l inf -np -nH
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/
> # note the trailing slash is needed
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>



-- 
Sean

Re: [VOTE] Accumulo 1.6.0-RC4

[Josh Elser]

-1 Reading over the legal/licensing docs the ASF has up made me come to 
the conclusion that we should not be making a release with the files 
that Mike outlined missing the header.


I'm still working on tests locally to verify things which have otherwise 
been going well. I'll try to report back later for full context.


On 4/28/14, 12:20 PM, Mike Drob wrote:

-1

The good:

* Verified all signatures and checksums.
* Ran continuous ingest with binary artifact + custom built native maps.


The issues, but not enough to vote against:

* Encountered ACCUMULO-2741.
* Encountered ACCUMULO-2742.
* Source artifact missing .gitignore
** This has been discussed, and I'm voting for precedent here. We can agree
to disagree, and if this vote passes then a new precedent will have been
set.


The bad:

* CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD)
** Past discussion here: http://markmail.org/message/ulvovup36uaa2cav
** It seems like we agreed to only include changes from the current major
release line, but that is not 100% clear.

* Missing licence headers:
** README
** conf/examples/crypto/readme.txt
** test/compat/japi-compliance/README
** test/system/continuous/ScaleTest.odp
**
docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg

**
docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf

**
docs/src/main/latex/common/state_diagrams/tablet_states.odg

** docs/src/main/latex/common/state_diagrams/tablet_states.pdf

On Fri, Apr 25, 2014 at 8:35 PM, Christopher  wrote:


Accumulo Developers,

Please consider the following candidate for Accumulo 1.6.0.

Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
Branch: 1.6.0-RC4

Staging repo:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
Source:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
Binary:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
(Append ".sha1", ".md5" or ".asc" to download the signature/hash for a
given artifact.)

All artifacts were built and staged with:
mvn release:prepare && mvn release:perform

Signing keys available at: https://www.apache.org/dist/accumulo/KEYS

Release notes (in progress):
http://accumulo.apache.org/release_notes/1.6.0

Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):

https://issues.apache.org/jira/browse/ACCUMULO-1219
https://issues.apache.org/jira/browse/ACCUMULO-2523
https://issues.apache.org/jira/browse/ACCUMULO-2569
https://issues.apache.org/jira/browse/ACCUMULO-2654
https://issues.apache.org/jira/browse/ACCUMULO-2707
https://issues.apache.org/jira/browse/ACCUMULO-2713
https://issues.apache.org/jira/browse/ACCUMULO-2714
https://issues.apache.org/jira/browse/ACCUMULO-2715
https://issues.apache.org/jira/browse/ACCUMULO-2716
https://issues.apache.org/jira/browse/ACCUMULO-2717
https://issues.apache.org/jira/browse/ACCUMULO-2718
https://issues.apache.org/jira/browse/ACCUMULO-2720
https://issues.apache.org/jira/browse/ACCUMULO-2723
https://issues.apache.org/jira/browse/ACCUMULO-2726
https://issues.apache.org/jira/browse/ACCUMULO-2728
https://issues.apache.org/jira/browse/ACCUMULO-2729
https://issues.apache.org/jira/browse/ACCUMULO-2733
https://issues.apache.org/jira/browse/ACCUMULO-2734

This vote will remain open for 72 hours (3 days), until Tue, 2014
April 28 01:00 UTC.
(That's 9pm EDT on Monday.)

[ ] +1 - I have verified and accept...
[ ] +0 - I have reservations, but not strong enough to vote against...
[ ] -1 - Because..., I do not accept...
... these artifacts as the 1.6.0 release of Apache Accumulo.

Thanks.

P.S. Hint: download the whole staging repo with
wget -erobots=off -r -l inf -np -nH
https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/
# note the trailing slash is needed

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

Re: [DISCUSS] Accumulo 1.6.0-RC4

[Billie Rinaldi]

On Mon, Apr 28, 2014 at 2:23 PM, Mike Drob  wrote:

> On Mon, Apr 28, 2014 at 5:12 PM, Christopher  wrote:
>
> > On Mon, Apr 28, 2014 at 3:24 PM, Mike Drob  wrote:
> > > Forking thread for discussion.
> > >
> > > On Mon, Apr 28, 2014 at 2:51 PM, Christopher 
> > wrote:
> > >
> > >> On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob 
> > wrote:
> > >> > -1
> > >> >
> > >>  >
> > >> > * Missing licence headers:
> > >> > ** README
> > >> > ** conf/examples/crypto/readme.txt
> > >> > ** test/compat/japi-compliance/README
> > >> > ** test/system/continuous/ScaleTest.odp
> > >> > **
> > >> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
> > >> >
> > >> > **
> > >> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
> > >> >
> > >> > **
> > >> > docs/src/main/latex/common/state_diagrams/tablet_states.odg
> > >> >
> > >> > ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
> > >>
> > >> The rat check plugin typically ignores README/NOTICE/LICENSE files as
> > >> category "N" (for Notices). That's why it ignored the
> > >> japi-compliance/README and conf/examples/crypto/readme.txt. I think
> > >> it's expected that the LICENSE file covers them. At the very least, I
> > >> don't think they contain anything copyrightable that would necessitate
> > >> a license. But, for consistency, maybe we should add it anyway? I'm
> > >> not sure that consistency argument warrants blockage (for me), though.
> > >>
> > >> http://www.apache.org/legal/src-headers.html#faq-exceptions
> > >
> > > The README has plenty of intellectual creativity in its content, and is
> > > therefore subject to copyright claims. It could be argued that the
> other
> > > two README files are short enough to not have copyright-able content,
> but
> > > it doesn't sound like that's the case you want to make.
> > >
> > > There is also lengthy discussion on
> > > https://issues.apache.org/jira/browse/LEGAL-114 but again, that is
> > focused
> > > on small, non-creative files. Our README does not fall into that
> > category.
> > >
> >
> > Agreed. Sorry, I meant the two smaller files didn't have enough. I had
> > combined two paragraphs for succinctness and this distinction got
> > lost.
> >
> > We had previously ignored other README files, but then added licences to
> them in ACCUMULO-2534 when rat-plugin complained. I believe the assumption
> is that README files are generally minimal, but I do not want to speak for
> the developers in this case.
>
> I strongly believe that our README needs a licence header. I am under the
> impression that it never had one.
>
>
> >  >
> > >> The rest were ignored because the rat check does not check binary
> > >> files. These files should be covered by the LICENSE/NOTICE files.
> > >> Binary document files may or may not be capable of supporting license
> > >> metadata, in general, but I think the coverage by the LICENSE/NOTICE
> > >> files is sufficient. However, we can do additional things with these
> > >> files. The ScaleTest.odp could probably be converted to markdown, with
> > >> a license header. The state_diagrams are not used anywhere in the
> > >> LaTeX generation (leftover from old developer manual?), and could
> > >> probably be deleted or moved to the website or wiki, if they are
> > >> needed at all. I'm not sure which option is best. However, again, I'd
> > >> consider the LICENSE/NOTICE files sufficient, so as not to block,
> > >> especially since they didn't block any previous release (presumably
> > >> because LICENSE/NOTICE covered them), and they've been around awhile.
> > >>
> > >
> > > I do not agree that "in general, coverage by LICENSE files is
> sufficient.
> > > If that were the case, then we would not need to put headers on our
> > source
> > > files, on our markdown files, on our example configuration files,
> etc...
> > >
> > > I also do not accept "they've been around for a while and nobody
> noticed
> > > it" as a reason to continue to ignore them. Either they are a
> violation,
> > or
> > > they are not. This is not to say that we have been perfect in the past,
> > but
> > > instead we correct mistakes when they are brought to attention.
> >
> > No, the "in general" part I was referring to only was for binary
> > files, which cannot be labeled without altering the contents. That is
> > not the case here (if the document formats allow metadata), but a
> > general explanation of the assumptions that the RAT check makes. I
> > also agree precedent should not determine the correct course of
> > action. The comment about precedent was specifically made in the
> > context of the parenthetical presumption... if that presumption does
> > not hold, and they did not block for some other reason (oversight, for
> > example), that is a different statement entirely.
> >
>
> It makes sense for rat-plugin to ignore binary files because they could be
> encrypted or compressed or something else, and already have a license
> header (false positives) or are simply impossible to a

Re: [VOTE] Accumulo 1.6.0-RC4

[Keith Turner]

I am seeing consistently slower write rates when comparing 1.5.1 and
1.6.0.   Following env :

   * hadoop 2.2.0
   * Zookeeper 3.4.5
   * Centos 6 (native, not a VM)
   * using examples/3GB/native-standalone config
   * setting tserver.mutation.queue.max 4M
   * I am running test/system/test1/ingest_test.sh
   * single node

Saw the following rates

  1.5.1 aggregate rate : 200,806 records/sec
  1.6.0 aggregate rate : 181,264 records/sec (90%)

Reran test setting  table.walog.enabled=false

  1.5.1 aggregate rate : 302,307 records/sec
  1.6.0 aggregate rate : 232,685 records/sec (77%)

I am not sure whats causing this.  Has anyone else tried anything like
this?  Given the gap is larger when walogs are turned off, this may not be
walog related.





On Mon, Apr 28, 2014 at 3:51 PM, Bill Havanki wrote:

> -0
>
> With the spate of blockers uncovered during the rc process so far
> [1][2][3], I'm uncomfortable approving the release so quickly after the
> most recent one was resolved. It's true there was a measure of luck in
> these being found when they were, but they appear to be indications that
> the code hasn't been up to snuff until very recently. My vote means "I'd
> rather wait some short amount of time to be sure".
>
> *However*, 1.6.0 really does need to be released, so I'm not willing to go
> all the way with -1. A blocker could come in the day after the eventual
> passing rc, no matter how long we might wait.
>
> In case of passage, tests I've run on rc4 so far: unit tests pass,
> functional tests pass, randomwalk ShortEach passes; randomwalk LongEach in
> progress. (randomwalk on 7-node cluster, 2 masters, 5 tservers, 3 zk, CDH
> 4.5)
>
> [1] https://issues.apache.org/jira/browse/ACCUMULO-2668
> [2] https://issues.apache.org/jira/browse/ACCUMULO-2700
> [3] https://issues.apache.org/jira/browse/ACCUMULO-2713
>
> Bill H
>
> On Mon, Apr 28, 2014 at 2:51 PM, Christopher  wrote:
>
> > On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob  wrote:
> > > -1
> > >
> > > The good:
> > >
> > > * Verified all signatures and checksums.
> > > * Ran continuous ingest with binary artifact + custom built native
> maps.
> > >
> > >
> > > The issues, but not enough to vote against:
> > >
> > > * Encountered ACCUMULO-2741.
> > > * Encountered ACCUMULO-2742.
> > > * Source artifact missing .gitignore
> > > ** This has been discussed, and I'm voting for precedent here. We can
> > agree
> > > to disagree, and if this vote passes then a new precedent will have
> been
> > > set.
> > >
> > >
> > > The bad:
> > >
> > > * CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD)
> > > ** Past discussion here: http://markmail.org/message/ulvovup36uaa2cav
> > > ** It seems like we agreed to only include changes from the current
> major
> > > release line, but that is not 100% clear.
> >
> > My understanding from that prior conversation is that, with the way we
> > use JIRA to mark things as fixed in the latest major release and
> > enumerating the fix versions to denote all the bugfix releases in
> > which it was fixed, meant that we can cover the entire CHANGE history
> > (after a certain point) by including only the major releases, and the
> > bugfixes since the last major one. Therefore, since this is a major
> > release, I included the 1.4.0 and 1.5.0 changes also. Anything fixed
> > in 1.5.1 would also be marked as fixed for 1.6.0 (if it still
> > applied), so the 1.6.0 changes include those and 1.5.1 is not needed
> > to list separately. This was not done for 1.5.0, because we hadn't
> > discussed it then.
> >
> > It seems you came to a different understanding from that conversation.
> > If I understand you correctly, it would mean we should only include
> > 1.6.0 changes? If that's the case, do you think a -1 is warranted for
> > including more than necessary (1.4.0 and 1.5.0)?
> >
> > >
> > > * Missing licence headers:
> > > ** README
> > > ** conf/examples/crypto/readme.txt
> > > ** test/compat/japi-compliance/README
> > > ** test/system/continuous/ScaleTest.odp
> > > **
> > > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
> > >
> > > **
> > > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
> > >
> > > **
> > > docs/src/main/latex/common/state_diagrams/tablet_states.odg
> > >
> > > ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
> >
> > The rat check plugin typically ignores README/NOTICE/LICENSE files as
> > category "N" (for Notices). That's why it ignored the
> > japi-compliance/README and conf/examples/crypto/readme.txt. I think
> > it's expected that the LICENSE file covers them. At the very least, I
> > don't think they contain anything copyrightable that would necessitate
> > a license. But, for consistency, maybe we should add it anyway? I'm
> > not sure that consistency argument warrants blockage (for me), though.
> >
> > The rest were ignored because the rat check does not check binary
> > files. These files should be covered by the LICENSE/NOTICE files.
> > Binary document fil

Re: [DISCUSS] Accumulo 1.6.0-RC4

[Mike Drob]

On Mon, Apr 28, 2014 at 5:12 PM, Christopher  wrote:

> On Mon, Apr 28, 2014 at 3:24 PM, Mike Drob  wrote:
> > Forking thread for discussion.
> >
> > On Mon, Apr 28, 2014 at 2:51 PM, Christopher 
> wrote:
> >
> >> On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob 
> wrote:
> >> > -1
> >> >
> >>  >
> >> > * Missing licence headers:
> >> > ** README
> >> > ** conf/examples/crypto/readme.txt
> >> > ** test/compat/japi-compliance/README
> >> > ** test/system/continuous/ScaleTest.odp
> >> > **
> >> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
> >> >
> >> > **
> >> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
> >> >
> >> > **
> >> > docs/src/main/latex/common/state_diagrams/tablet_states.odg
> >> >
> >> > ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
> >>
> >> The rat check plugin typically ignores README/NOTICE/LICENSE files as
> >> category "N" (for Notices). That's why it ignored the
> >> japi-compliance/README and conf/examples/crypto/readme.txt. I think
> >> it's expected that the LICENSE file covers them. At the very least, I
> >> don't think they contain anything copyrightable that would necessitate
> >> a license. But, for consistency, maybe we should add it anyway? I'm
> >> not sure that consistency argument warrants blockage (for me), though.
> >>
> >> http://www.apache.org/legal/src-headers.html#faq-exceptions
> >
> > The README has plenty of intellectual creativity in its content, and is
> > therefore subject to copyright claims. It could be argued that the other
> > two README files are short enough to not have copyright-able content, but
> > it doesn't sound like that's the case you want to make.
> >
> > There is also lengthy discussion on
> > https://issues.apache.org/jira/browse/LEGAL-114 but again, that is
> focused
> > on small, non-creative files. Our README does not fall into that
> category.
> >
>
> Agreed. Sorry, I meant the two smaller files didn't have enough. I had
> combined two paragraphs for succinctness and this distinction got
> lost.
>
> We had previously ignored other README files, but then added licences to
them in ACCUMULO-2534 when rat-plugin complained. I believe the assumption
is that README files are generally minimal, but I do not want to speak for
the developers in this case.

I strongly believe that our README needs a licence header. I am under the
impression that it never had one.


>  >
> >> The rest were ignored because the rat check does not check binary
> >> files. These files should be covered by the LICENSE/NOTICE files.
> >> Binary document files may or may not be capable of supporting license
> >> metadata, in general, but I think the coverage by the LICENSE/NOTICE
> >> files is sufficient. However, we can do additional things with these
> >> files. The ScaleTest.odp could probably be converted to markdown, with
> >> a license header. The state_diagrams are not used anywhere in the
> >> LaTeX generation (leftover from old developer manual?), and could
> >> probably be deleted or moved to the website or wiki, if they are
> >> needed at all. I'm not sure which option is best. However, again, I'd
> >> consider the LICENSE/NOTICE files sufficient, so as not to block,
> >> especially since they didn't block any previous release (presumably
> >> because LICENSE/NOTICE covered them), and they've been around awhile.
> >>
> >
> > I do not agree that "in general, coverage by LICENSE files is sufficient.
> > If that were the case, then we would not need to put headers on our
> source
> > files, on our markdown files, on our example configuration files, etc...
> >
> > I also do not accept "they've been around for a while and nobody noticed
> > it" as a reason to continue to ignore them. Either they are a violation,
> or
> > they are not. This is not to say that we have been perfect in the past,
> but
> > instead we correct mistakes when they are brought to attention.
>
> No, the "in general" part I was referring to only was for binary
> files, which cannot be labeled without altering the contents. That is
> not the case here (if the document formats allow metadata), but a
> general explanation of the assumptions that the RAT check makes. I
> also agree precedent should not determine the correct course of
> action. The comment about precedent was specifically made in the
> context of the parenthetical presumption... if that presumption does
> not hold, and they did not block for some other reason (oversight, for
> example), that is a different statement entirely.
>

It makes sense for rat-plugin to ignore binary files because they could be
encrypted or compressed or something else, and already have a license
header (false positives) or are simply impossible to add a header to
because they are machine generated.

If these files have licence headers somewhere in them, then I will withdraw
my concern over them. I felt that I performed due diligence by visually
inspecting them, running them through "strings" program, and attempting

Re: [VOTE] Accumulo 1.6.0-RC4

[Christopher]

Going to vote +0 myself, for the license issues Mike points out.
I don't have an opinion about the CHANGES file, but I'd like consensus
before changing it again.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob  wrote:
> -1
>
> The good:
>
> * Verified all signatures and checksums.
> * Ran continuous ingest with binary artifact + custom built native maps.
>
>
> The issues, but not enough to vote against:
>
> * Encountered ACCUMULO-2741.
> * Encountered ACCUMULO-2742.
> * Source artifact missing .gitignore
> ** This has been discussed, and I'm voting for precedent here. We can agree
> to disagree, and if this vote passes then a new precedent will have been
> set.
>
>
> The bad:
>
> * CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD)
> ** Past discussion here: http://markmail.org/message/ulvovup36uaa2cav
> ** It seems like we agreed to only include changes from the current major
> release line, but that is not 100% clear.
>
> * Missing licence headers:
> ** README
> ** conf/examples/crypto/readme.txt
> ** test/compat/japi-compliance/README
> ** test/system/continuous/ScaleTest.odp
> **
> docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
>
> **
> docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
>
> **
> docs/src/main/latex/common/state_diagrams/tablet_states.odg
>
> ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
>
> On Fri, Apr 25, 2014 at 8:35 PM, Christopher  wrote:
>
>> Accumulo Developers,
>>
>> Please consider the following candidate for Accumulo 1.6.0.
>>
>> Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
>> Branch: 1.6.0-RC4
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
>> Source:
>> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
>> Binary:
>> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
>> (Append ".sha1", ".md5" or ".asc" to download the signature/hash for a
>> given artifact.)
>>
>> All artifacts were built and staged with:
>> mvn release:prepare && mvn release:perform
>>
>> Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
>>
>> Release notes (in progress):
>> http://accumulo.apache.org/release_notes/1.6.0
>>
>> Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):
>>
>> https://issues.apache.org/jira/browse/ACCUMULO-1219
>> https://issues.apache.org/jira/browse/ACCUMULO-2523
>> https://issues.apache.org/jira/browse/ACCUMULO-2569
>> https://issues.apache.org/jira/browse/ACCUMULO-2654
>> https://issues.apache.org/jira/browse/ACCUMULO-2707
>> https://issues.apache.org/jira/browse/ACCUMULO-2713
>> https://issues.apache.org/jira/browse/ACCUMULO-2714
>> https://issues.apache.org/jira/browse/ACCUMULO-2715
>> https://issues.apache.org/jira/browse/ACCUMULO-2716
>> https://issues.apache.org/jira/browse/ACCUMULO-2717
>> https://issues.apache.org/jira/browse/ACCUMULO-2718
>> https://issues.apache.org/jira/browse/ACCUMULO-2720
>> https://issues.apache.org/jira/browse/ACCUMULO-2723
>> https://issues.apache.org/jira/browse/ACCUMULO-2726
>> https://issues.apache.org/jira/browse/ACCUMULO-2728
>> https://issues.apache.org/jira/browse/ACCUMULO-2729
>> https://issues.apache.org/jira/browse/ACCUMULO-2733
>> https://issues.apache.org/jira/browse/ACCUMULO-2734
>>
>> This vote will remain open for 72 hours (3 days), until Tue, 2014
>> April 28 01:00 UTC.
>> (That's 9pm EDT on Monday.)
>>
>> [ ] +1 - I have verified and accept...
>> [ ] +0 - I have reservations, but not strong enough to vote against...
>> [ ] -1 - Because..., I do not accept...
>> ... these artifacts as the 1.6.0 release of Apache Accumulo.
>>
>> Thanks.
>>
>> P.S. Hint: download the whole staging repo with
>> wget -erobots=off -r -l inf -np -nH
>> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/
>> # note the trailing slash is needed
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>

Re: Review Request 20790: ACCUMULO-2742 offset history command by one

[Mike Drob]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20790/
---

(Updated April 28, 2014, 9:14 p.m.)


Review request for accumulo.


Changes
---

Use platform independent new-line, because I think OS X behaves funny with 
JLine.


Bugs: ACCUMULO-2742
https://issues.apache.org/jira/browse/ACCUMULO-2742


Repository: accumulo


Description
---

ACCUMULO-2742 offset history command by one

The history entries returned by the history command are 0-indexed,
while the history expansion is 1-indexed. We need to offset the index
when we print it so that users can accurately use event expansion.


Diffs (updated)
-

  
core/src/main/java/org/apache/accumulo/core/util/shell/commands/HistoryCommand.java
 9531d903aca834ab3b70650824023061e7e788d9 
  
core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java
 PRE-CREATION 

Diff: https://reviews.apache.org/r/20790/diff/


Testing
---

New unit test. Verified on cluster deployment.


Thanks,

Mike Drob

Re: [DISCUSS] Accumulo 1.6.0-RC4

[Christopher]

On Mon, Apr 28, 2014 at 3:24 PM, Mike Drob  wrote:
> Forking thread for discussion.
>
> On Mon, Apr 28, 2014 at 2:51 PM, Christopher  wrote:
>
>> On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob  wrote:
>> > -1
>> >
>> > The good:
>> >
>> > * Verified all signatures and checksums.
>> > * Ran continuous ingest with binary artifact + custom built native maps.
>> >
>> >
>> > The issues, but not enough to vote against:
>> >
>> > * Encountered ACCUMULO-2741.
>> > * Encountered ACCUMULO-2742.
>> > * Source artifact missing .gitignore
>> > ** This has been discussed, and I'm voting for precedent here. We can
>> agree
>> > to disagree, and if this vote passes then a new precedent will have been
>> > set.
>> >
>> >
>> > The bad:
>> >
>> > * CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD)
>> > ** Past discussion here: http://markmail.org/message/ulvovup36uaa2cav
>> > ** It seems like we agreed to only include changes from the current major
>> > release line, but that is not 100% clear.
>>
>> My understanding from that prior conversation is that, with the way we
>> use JIRA to mark things as fixed in the latest major release and
>> enumerating the fix versions to denote all the bugfix releases in
>> which it was fixed, meant that we can cover the entire CHANGE history
>> (after a certain point) by including only the major releases, and the
>> bugfixes since the last major one. Therefore, since this is a major
>> release, I included the 1.4.0 and 1.5.0 changes also. Anything fixed
>> in 1.5.1 would also be marked as fixed for 1.6.0 (if it still
>> applied), so the 1.6.0 changes include those and 1.5.1 is not needed
>> to list separately. This was not done for 1.5.0, because we hadn't
>> discussed it then.
>>
>> It seems you came to a different understanding from that conversation.
>> If I understand you correctly, it would mean we should only include
>> 1.6.0 changes? If that's the case, do you think a -1 is warranted for
>> including more than necessary (1.4.0 and 1.5.0)?
>>
>> Yes, my understanding was that only 1.6.0 changes would be present. Yes, I
> believe that this warrants a -1.
>
>
>>  >
>> > * Missing licence headers:
>> > ** README
>> > ** conf/examples/crypto/readme.txt
>> > ** test/compat/japi-compliance/README
>> > ** test/system/continuous/ScaleTest.odp
>> > **
>> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
>> >
>> > **
>> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
>> >
>> > **
>> > docs/src/main/latex/common/state_diagrams/tablet_states.odg
>> >
>> > ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
>>
>> The rat check plugin typically ignores README/NOTICE/LICENSE files as
>> category "N" (for Notices). That's why it ignored the
>> japi-compliance/README and conf/examples/crypto/readme.txt. I think
>> it's expected that the LICENSE file covers them. At the very least, I
>> don't think they contain anything copyrightable that would necessitate
>> a license. But, for consistency, maybe we should add it anyway? I'm
>> not sure that consistency argument warrants blockage (for me), though.
>>
>> http://www.apache.org/legal/src-headers.html#faq-exceptions
>
> The README has plenty of intellectual creativity in its content, and is
> therefore subject to copyright claims. It could be argued that the other
> two README files are short enough to not have copyright-able content, but
> it doesn't sound like that's the case you want to make.
>
> There is also lengthy discussion on
> https://issues.apache.org/jira/browse/LEGAL-114 but again, that is focused
> on small, non-creative files. Our README does not fall into that category.
>

Agreed. Sorry, I meant the two smaller files didn't have enough. I had
combined two paragraphs for succinctness and this distinction got
lost.

>
>> The rest were ignored because the rat check does not check binary
>> files. These files should be covered by the LICENSE/NOTICE files.
>> Binary document files may or may not be capable of supporting license
>> metadata, in general, but I think the coverage by the LICENSE/NOTICE
>> files is sufficient. However, we can do additional things with these
>> files. The ScaleTest.odp could probably be converted to markdown, with
>> a license header. The state_diagrams are not used anywhere in the
>> LaTeX generation (leftover from old developer manual?), and could
>> probably be deleted or moved to the website or wiki, if they are
>> needed at all. I'm not sure which option is best. However, again, I'd
>> consider the LICENSE/NOTICE files sufficient, so as not to block,
>> especially since they didn't block any previous release (presumably
>> because LICENSE/NOTICE covered them), and they've been around awhile.
>>
>
> I do not agree that "in general, coverage by LICENSE files is sufficient.
> If that were the case, then we would not need to put headers on our source
> files, on our markdown files, on our example configuration files, etc...
>
> I also do not accept "they've been around for

Re: Review Request 20790: ACCUMULO-2742 offset history command by one

[Mike Drob]

> On April 28, 2014, 8:57 p.m., Christopher Tubbs wrote:
> > core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java,
> >  lines 76-81
> > 
> >
> > This test fails.
> 
> Christopher Tubbs wrote:
> I should have clarified. The assertion fails. The test does not throw an 
> exception. The value of baos.toString().trim() appears to be the empty string.

Hrm. Are you running from Eclipse or Maven command line? What Java? It works on 
my machine using both Eclipse and command line, and Oracle Java 6 and Java 7. 
Does it pass if you add a reader.flush() before the assertion?


- Mike


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20790/#review41635
---


On April 28, 2014, 7:40 p.m., Mike Drob wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20790/
> ---
> 
> (Updated April 28, 2014, 7:40 p.m.)
> 
> 
> Review request for accumulo.
> 
> 
> Bugs: ACCUMULO-2742
> https://issues.apache.org/jira/browse/ACCUMULO-2742
> 
> 
> Repository: accumulo
> 
> 
> Description
> ---
> 
> ACCUMULO-2742 offset history command by one
> 
> The history entries returned by the history command are 0-indexed,
> while the history expansion is 1-indexed. We need to offset the index
> when we print it so that users can accurately use event expansion.
> 
> 
> Diffs
> -
> 
>   
> core/src/main/java/org/apache/accumulo/core/util/shell/commands/HistoryCommand.java
>  9531d903aca834ab3b70650824023061e7e788d9 
>   
> core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/20790/diff/
> 
> 
> Testing
> ---
> 
> New unit test. Verified on cluster deployment.
> 
> 
> Thanks,
> 
> Mike Drob
> 
>

Re: Hadoop Summit (San Jose June 3-5)

[Billie Rinaldi]

Just announced, an Accumulo Birds of a Feather session at the Hadoop Summit:
http://www.meetup.com/Hadoop-Summit-Community-San-Jose/events/179840512/

It looks like we have an hour and a half, exact schedule TBD.  Feel free to
contact me if there is any particular content you'd like to see at this
session.

Billie


On Mon, Apr 28, 2014 at 8:52 AM, Donald Miner wrote:

> I'll be there. Is there interest in having an accumulo meetup like last
> year? Adam/Billie?
>
>
> On Mon, Apr 28, 2014 at 11:50 AM, Marc Reichman <
> mreich...@pixelforensics.com> wrote:
>
>> Will anyone be there? I wouldn't mind meeting up for a drink, talk about
>> Accumulo, projects, etc.
>>
>> Looking forward to coming to my first Hadoop-based conference!
>>
>> Marc
>>
>
>
>
> --
>
> Donald Miner
> Chief Technology Officer
> ClearEdge IT Solutions, LLC
> Cell: 443 799 7807
> www.clearedgeit.com
>

Re: Review Request 20790: ACCUMULO-2742 offset history command by one

[Christopher Tubbs]

> On April 28, 2014, 4:57 p.m., Christopher Tubbs wrote:
> > core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java,
> >  lines 76-81
> > 
> >
> > This test fails.

I should have clarified. The assertion fails. The test does not throw an 
exception. The value of baos.toString().trim() appears to be the empty string.


- Christopher


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20790/#review41635
---


On April 28, 2014, 3:40 p.m., Mike Drob wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20790/
> ---
> 
> (Updated April 28, 2014, 3:40 p.m.)
> 
> 
> Review request for accumulo.
> 
> 
> Bugs: ACCUMULO-2742
> https://issues.apache.org/jira/browse/ACCUMULO-2742
> 
> 
> Repository: accumulo
> 
> 
> Description
> ---
> 
> ACCUMULO-2742 offset history command by one
> 
> The history entries returned by the history command are 0-indexed,
> while the history expansion is 1-indexed. We need to offset the index
> when we print it so that users can accurately use event expansion.
> 
> 
> Diffs
> -
> 
>   
> core/src/main/java/org/apache/accumulo/core/util/shell/commands/HistoryCommand.java
>  9531d903aca834ab3b70650824023061e7e788d9 
>   
> core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/20790/diff/
> 
> 
> Testing
> ---
> 
> New unit test. Verified on cluster deployment.
> 
> 
> Thanks,
> 
> Mike Drob
> 
>

Re: Review Request 20790: ACCUMULO-2742 offset history command by one

[Christopher Tubbs]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20790/#review41635
---



core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java


This test fails.


- Christopher Tubbs


On April 28, 2014, 3:40 p.m., Mike Drob wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20790/
> ---
> 
> (Updated April 28, 2014, 3:40 p.m.)
> 
> 
> Review request for accumulo.
> 
> 
> Bugs: ACCUMULO-2742
> https://issues.apache.org/jira/browse/ACCUMULO-2742
> 
> 
> Repository: accumulo
> 
> 
> Description
> ---
> 
> ACCUMULO-2742 offset history command by one
> 
> The history entries returned by the history command are 0-indexed,
> while the history expansion is 1-indexed. We need to offset the index
> when we print it so that users can accurately use event expansion.
> 
> 
> Diffs
> -
> 
>   
> core/src/main/java/org/apache/accumulo/core/util/shell/commands/HistoryCommand.java
>  9531d903aca834ab3b70650824023061e7e788d9 
>   
> core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/20790/diff/
> 
> 
> Testing
> ---
> 
> New unit test. Verified on cluster deployment.
> 
> 
> Thanks,
> 
> Mike Drob
> 
>

Re: [VOTE] Accumulo 1.6.0-RC4

[John Vines]

+1


On Fri, Apr 25, 2014 at 8:35 PM, Christopher  wrote:

> Accumulo Developers,
>
> Please consider the following candidate for Accumulo 1.6.0.
>
> Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
> Branch: 1.6.0-RC4
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
> Source:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
> Binary:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
> (Append ".sha1", ".md5" or ".asc" to download the signature/hash for a
> given artifact.)
>
> All artifacts were built and staged with:
> mvn release:prepare && mvn release:perform
>
> Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
>
> Release notes (in progress):
> http://accumulo.apache.org/release_notes/1.6.0
>
> Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):
>
> https://issues.apache.org/jira/browse/ACCUMULO-1219
> https://issues.apache.org/jira/browse/ACCUMULO-2523
> https://issues.apache.org/jira/browse/ACCUMULO-2569
> https://issues.apache.org/jira/browse/ACCUMULO-2654
> https://issues.apache.org/jira/browse/ACCUMULO-2707
> https://issues.apache.org/jira/browse/ACCUMULO-2713
> https://issues.apache.org/jira/browse/ACCUMULO-2714
> https://issues.apache.org/jira/browse/ACCUMULO-2715
> https://issues.apache.org/jira/browse/ACCUMULO-2716
> https://issues.apache.org/jira/browse/ACCUMULO-2717
> https://issues.apache.org/jira/browse/ACCUMULO-2718
> https://issues.apache.org/jira/browse/ACCUMULO-2720
> https://issues.apache.org/jira/browse/ACCUMULO-2723
> https://issues.apache.org/jira/browse/ACCUMULO-2726
> https://issues.apache.org/jira/browse/ACCUMULO-2728
> https://issues.apache.org/jira/browse/ACCUMULO-2729
> https://issues.apache.org/jira/browse/ACCUMULO-2733
> https://issues.apache.org/jira/browse/ACCUMULO-2734
>
> This vote will remain open for 72 hours (3 days), until Tue, 2014
> April 28 01:00 UTC.
> (That's 9pm EDT on Monday.)
>
> [ ] +1 - I have verified and accept...
> [ ] +0 - I have reservations, but not strong enough to vote against...
> [ ] -1 - Because..., I do not accept...
> ... these artifacts as the 1.6.0 release of Apache Accumulo.
>
> Thanks.
>
> P.S. Hint: download the whole staging repo with
> wget -erobots=off -r -l inf -np -nH
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/
> # note the trailing slash is needed
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>

Re: [VOTE] Accumulo 1.6.0-RC4

[Bill Havanki]

-0

With the spate of blockers uncovered during the rc process so far
[1][2][3], I'm uncomfortable approving the release so quickly after the
most recent one was resolved. It's true there was a measure of luck in
these being found when they were, but they appear to be indications that
the code hasn't been up to snuff until very recently. My vote means "I'd
rather wait some short amount of time to be sure".

*However*, 1.6.0 really does need to be released, so I'm not willing to go
all the way with -1. A blocker could come in the day after the eventual
passing rc, no matter how long we might wait.

In case of passage, tests I've run on rc4 so far: unit tests pass,
functional tests pass, randomwalk ShortEach passes; randomwalk LongEach in
progress. (randomwalk on 7-node cluster, 2 masters, 5 tservers, 3 zk, CDH
4.5)

[1] https://issues.apache.org/jira/browse/ACCUMULO-2668
[2] https://issues.apache.org/jira/browse/ACCUMULO-2700
[3] https://issues.apache.org/jira/browse/ACCUMULO-2713

Bill H

On Mon, Apr 28, 2014 at 2:51 PM, Christopher  wrote:

> On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob  wrote:
> > -1
> >
> > The good:
> >
> > * Verified all signatures and checksums.
> > * Ran continuous ingest with binary artifact + custom built native maps.
> >
> >
> > The issues, but not enough to vote against:
> >
> > * Encountered ACCUMULO-2741.
> > * Encountered ACCUMULO-2742.
> > * Source artifact missing .gitignore
> > ** This has been discussed, and I'm voting for precedent here. We can
> agree
> > to disagree, and if this vote passes then a new precedent will have been
> > set.
> >
> >
> > The bad:
> >
> > * CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD)
> > ** Past discussion here: http://markmail.org/message/ulvovup36uaa2cav
> > ** It seems like we agreed to only include changes from the current major
> > release line, but that is not 100% clear.
>
> My understanding from that prior conversation is that, with the way we
> use JIRA to mark things as fixed in the latest major release and
> enumerating the fix versions to denote all the bugfix releases in
> which it was fixed, meant that we can cover the entire CHANGE history
> (after a certain point) by including only the major releases, and the
> bugfixes since the last major one. Therefore, since this is a major
> release, I included the 1.4.0 and 1.5.0 changes also. Anything fixed
> in 1.5.1 would also be marked as fixed for 1.6.0 (if it still
> applied), so the 1.6.0 changes include those and 1.5.1 is not needed
> to list separately. This was not done for 1.5.0, because we hadn't
> discussed it then.
>
> It seems you came to a different understanding from that conversation.
> If I understand you correctly, it would mean we should only include
> 1.6.0 changes? If that's the case, do you think a -1 is warranted for
> including more than necessary (1.4.0 and 1.5.0)?
>
> >
> > * Missing licence headers:
> > ** README
> > ** conf/examples/crypto/readme.txt
> > ** test/compat/japi-compliance/README
> > ** test/system/continuous/ScaleTest.odp
> > **
> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
> >
> > **
> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
> >
> > **
> > docs/src/main/latex/common/state_diagrams/tablet_states.odg
> >
> > ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
>
> The rat check plugin typically ignores README/NOTICE/LICENSE files as
> category "N" (for Notices). That's why it ignored the
> japi-compliance/README and conf/examples/crypto/readme.txt. I think
> it's expected that the LICENSE file covers them. At the very least, I
> don't think they contain anything copyrightable that would necessitate
> a license. But, for consistency, maybe we should add it anyway? I'm
> not sure that consistency argument warrants blockage (for me), though.
>
> The rest were ignored because the rat check does not check binary
> files. These files should be covered by the LICENSE/NOTICE files.
> Binary document files may or may not be capable of supporting license
> metadata, in general, but I think the coverage by the LICENSE/NOTICE
> files is sufficient. However, we can do additional things with these
> files. The ScaleTest.odp could probably be converted to markdown, with
> a license header. The state_diagrams are not used anywhere in the
> LaTeX generation (leftover from old developer manual?), and could
> probably be deleted or moved to the website or wiki, if they are
> needed at all. I'm not sure which option is best. However, again, I'd
> consider the LICENSE/NOTICE files sufficient, so as not to block,
> especially since they didn't block any previous release (presumably
> because LICENSE/NOTICE covered them), and they've been around awhile.
>



-- 
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283

Re: Review Request 20790: ACCUMULO-2742 offset history command by one

[Mike Drob]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20790/
---

(Updated April 28, 2014, 7:40 p.m.)


Review request for accumulo.


Changes
---

Added separate unit tests to check for separate conditions.


Bugs: ACCUMULO-2742
https://issues.apache.org/jira/browse/ACCUMULO-2742


Repository: accumulo


Description
---

ACCUMULO-2742 offset history command by one

The history entries returned by the history command are 0-indexed,
while the history expansion is 1-indexed. We need to offset the index
when we print it so that users can accurately use event expansion.


Diffs (updated)
-

  
core/src/main/java/org/apache/accumulo/core/util/shell/commands/HistoryCommand.java
 9531d903aca834ab3b70650824023061e7e788d9 
  
core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java
 PRE-CREATION 

Diff: https://reviews.apache.org/r/20790/diff/


Testing
---

New unit test. Verified on cluster deployment.


Thanks,

Mike Drob

Re: Review Request 20790: ACCUMULO-2742 offset history command by one

[Bill Havanki]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20790/#review41625
---



core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java


I'm confused - this appears to be testing that the ! event designator 
works, and not that the history is numbered correctly. (Sure, both should be 
tested.) I'd have figured there would be a test ensuring that the output was:

1: foo
2: bar


- Bill Havanki


On April 28, 2014, 3:18 p.m., Mike Drob wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20790/
> ---
> 
> (Updated April 28, 2014, 3:18 p.m.)
> 
> 
> Review request for accumulo.
> 
> 
> Bugs: ACCUMULO-2742
> https://issues.apache.org/jira/browse/ACCUMULO-2742
> 
> 
> Repository: accumulo
> 
> 
> Description
> ---
> 
> ACCUMULO-2742 offset history command by one
> 
> The history entries returned by the history command are 0-indexed,
> while the history expansion is 1-indexed. We need to offset the index
> when we print it so that users can accurately use event expansion.
> 
> 
> Diffs
> -
> 
>   
> core/src/main/java/org/apache/accumulo/core/util/shell/commands/HistoryCommand.java
>  9531d903aca834ab3b70650824023061e7e788d9 
>   
> core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/20790/diff/
> 
> 
> Testing
> ---
> 
> New unit test. Verified on cluster deployment.
> 
> 
> Thanks,
> 
> Mike Drob
> 
>

Re: [DISCUSS] Accumulo 1.6.0-RC4

[Mike Drob]

Forking thread for discussion.

On Mon, Apr 28, 2014 at 2:51 PM, Christopher  wrote:

> On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob  wrote:
> > -1
> >
> > The good:
> >
> > * Verified all signatures and checksums.
> > * Ran continuous ingest with binary artifact + custom built native maps.
> >
> >
> > The issues, but not enough to vote against:
> >
> > * Encountered ACCUMULO-2741.
> > * Encountered ACCUMULO-2742.
> > * Source artifact missing .gitignore
> > ** This has been discussed, and I'm voting for precedent here. We can
> agree
> > to disagree, and if this vote passes then a new precedent will have been
> > set.
> >
> >
> > The bad:
> >
> > * CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD)
> > ** Past discussion here: http://markmail.org/message/ulvovup36uaa2cav
> > ** It seems like we agreed to only include changes from the current major
> > release line, but that is not 100% clear.
>
> My understanding from that prior conversation is that, with the way we
> use JIRA to mark things as fixed in the latest major release and
> enumerating the fix versions to denote all the bugfix releases in
> which it was fixed, meant that we can cover the entire CHANGE history
> (after a certain point) by including only the major releases, and the
> bugfixes since the last major one. Therefore, since this is a major
> release, I included the 1.4.0 and 1.5.0 changes also. Anything fixed
> in 1.5.1 would also be marked as fixed for 1.6.0 (if it still
> applied), so the 1.6.0 changes include those and 1.5.1 is not needed
> to list separately. This was not done for 1.5.0, because we hadn't
> discussed it then.
>
> It seems you came to a different understanding from that conversation.
> If I understand you correctly, it would mean we should only include
> 1.6.0 changes? If that's the case, do you think a -1 is warranted for
> including more than necessary (1.4.0 and 1.5.0)?
>
> Yes, my understanding was that only 1.6.0 changes would be present. Yes, I
believe that this warrants a -1.


>  >
> > * Missing licence headers:
> > ** README
> > ** conf/examples/crypto/readme.txt
> > ** test/compat/japi-compliance/README
> > ** test/system/continuous/ScaleTest.odp
> > **
> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
> >
> > **
> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
> >
> > **
> > docs/src/main/latex/common/state_diagrams/tablet_states.odg
> >
> > ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
>
> The rat check plugin typically ignores README/NOTICE/LICENSE files as
> category "N" (for Notices). That's why it ignored the
> japi-compliance/README and conf/examples/crypto/readme.txt. I think
> it's expected that the LICENSE file covers them. At the very least, I
> don't think they contain anything copyrightable that would necessitate
> a license. But, for consistency, maybe we should add it anyway? I'm
> not sure that consistency argument warrants blockage (for me), though.
>
> http://www.apache.org/legal/src-headers.html#faq-exceptions

The README has plenty of intellectual creativity in its content, and is
therefore subject to copyright claims. It could be argued that the other
two README files are short enough to not have copyright-able content, but
it doesn't sound like that's the case you want to make.

There is also lengthy discussion on
https://issues.apache.org/jira/browse/LEGAL-114 but again, that is focused
on small, non-creative files. Our README does not fall into that category.


> The rest were ignored because the rat check does not check binary
> files. These files should be covered by the LICENSE/NOTICE files.
> Binary document files may or may not be capable of supporting license
> metadata, in general, but I think the coverage by the LICENSE/NOTICE
> files is sufficient. However, we can do additional things with these
> files. The ScaleTest.odp could probably be converted to markdown, with
> a license header. The state_diagrams are not used anywhere in the
> LaTeX generation (leftover from old developer manual?), and could
> probably be deleted or moved to the website or wiki, if they are
> needed at all. I'm not sure which option is best. However, again, I'd
> consider the LICENSE/NOTICE files sufficient, so as not to block,
> especially since they didn't block any previous release (presumably
> because LICENSE/NOTICE covered them), and they've been around awhile.
>

I do not agree that "in general, coverage by LICENSE files is sufficient.
If that were the case, then we would not need to put headers on our source
files, on our markdown files, on our example configuration files, etc...

I also do not accept "they've been around for a while and nobody noticed
it" as a reason to continue to ignore them. Either they are a violation, or
they are not. This is not to say that we have been perfect in the past, but
instead we correct mistakes when they are brought to attention.

Review Request 20790: ACCUMULO-2742 offset history command by one

[Mike Drob]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20790/
---

Review request for accumulo.


Bugs: ACCUMULO-2742
https://issues.apache.org/jira/browse/ACCUMULO-2742


Repository: accumulo


Description
---

ACCUMULO-2742 offset history command by one

The history entries returned by the history command are 0-indexed,
while the history expansion is 1-indexed. We need to offset the index
when we print it so that users can accurately use event expansion.


Diffs
-

  
core/src/main/java/org/apache/accumulo/core/util/shell/commands/HistoryCommand.java
 9531d903aca834ab3b70650824023061e7e788d9 
  
core/src/test/java/org/apache/accumulo/core/util/shell/command/HistoryCommandTest.java
 PRE-CREATION 

Diff: https://reviews.apache.org/r/20790/diff/


Testing
---

New unit test. Verified on cluster deployment.


Thanks,

Mike Drob

Re: [VOTE] Accumulo 1.6.0-RC4

[Christopher]

On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob  wrote:
> -1
>
> The good:
>
> * Verified all signatures and checksums.
> * Ran continuous ingest with binary artifact + custom built native maps.
>
>
> The issues, but not enough to vote against:
>
> * Encountered ACCUMULO-2741.
> * Encountered ACCUMULO-2742.
> * Source artifact missing .gitignore
> ** This has been discussed, and I'm voting for precedent here. We can agree
> to disagree, and if this vote passes then a new precedent will have been
> set.
>
>
> The bad:
>
> * CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD)
> ** Past discussion here: http://markmail.org/message/ulvovup36uaa2cav
> ** It seems like we agreed to only include changes from the current major
> release line, but that is not 100% clear.

My understanding from that prior conversation is that, with the way we
use JIRA to mark things as fixed in the latest major release and
enumerating the fix versions to denote all the bugfix releases in
which it was fixed, meant that we can cover the entire CHANGE history
(after a certain point) by including only the major releases, and the
bugfixes since the last major one. Therefore, since this is a major
release, I included the 1.4.0 and 1.5.0 changes also. Anything fixed
in 1.5.1 would also be marked as fixed for 1.6.0 (if it still
applied), so the 1.6.0 changes include those and 1.5.1 is not needed
to list separately. This was not done for 1.5.0, because we hadn't
discussed it then.

It seems you came to a different understanding from that conversation.
If I understand you correctly, it would mean we should only include
1.6.0 changes? If that's the case, do you think a -1 is warranted for
including more than necessary (1.4.0 and 1.5.0)?

>
> * Missing licence headers:
> ** README
> ** conf/examples/crypto/readme.txt
> ** test/compat/japi-compliance/README
> ** test/system/continuous/ScaleTest.odp
> **
> docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
>
> **
> docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
>
> **
> docs/src/main/latex/common/state_diagrams/tablet_states.odg
>
> ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf

The rat check plugin typically ignores README/NOTICE/LICENSE files as
category "N" (for Notices). That's why it ignored the
japi-compliance/README and conf/examples/crypto/readme.txt. I think
it's expected that the LICENSE file covers them. At the very least, I
don't think they contain anything copyrightable that would necessitate
a license. But, for consistency, maybe we should add it anyway? I'm
not sure that consistency argument warrants blockage (for me), though.

The rest were ignored because the rat check does not check binary
files. These files should be covered by the LICENSE/NOTICE files.
Binary document files may or may not be capable of supporting license
metadata, in general, but I think the coverage by the LICENSE/NOTICE
files is sufficient. However, we can do additional things with these
files. The ScaleTest.odp could probably be converted to markdown, with
a license header. The state_diagrams are not used anywhere in the
LaTeX generation (leftover from old developer manual?), and could
probably be deleted or moved to the website or wiki, if they are
needed at all. I'm not sure which option is best. However, again, I'd
consider the LICENSE/NOTICE files sufficient, so as not to block,
especially since they didn't block any previous release (presumably
because LICENSE/NOTICE covered them), and they've been around awhile.

Re: [VOTE] Accumulo 1.6.0-RC4

[Josh Elser]

On 4/28/14, 12:20 PM, Mike Drob wrote:

-1

The good:

* Verified all signatures and checksums.
* Ran continuous ingest with binary artifact + custom built native maps.


The issues, but not enough to vote against:

* Encountered ACCUMULO-2741.
* Encountered ACCUMULO-2742.
* Source artifact missing .gitignore
** This has been discussed, and I'm voting for precedent here. We can agree
to disagree, and if this vote passes then a new precedent will have been
set.


The bad:

* CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD)
** Past discussion here:http://markmail.org/message/ulvovup36uaa2cav
** It seems like we agreed to only include changes from the current major
release line, but that is not 100% clear.

* Missing licence headers:
** README
** conf/examples/crypto/readme.txt
** test/compat/japi-compliance/README
** test/system/continuous/ScaleTest.odp
**
docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg

**
docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf

**
docs/src/main/latex/common/state_diagrams/tablet_states.odg

** docs/src/main/latex/common/state_diagrams/tablet_states.pdf


Should we be trying to get a license included in a non-plaintext file? 
(odg, pdf, and odp)


I remember that ScaleTest presentation being an issue before we had the 
rat-check automated (correctly) in the build. I haven't seen it since we 
got the *apache*-rat-plugin configured.

Re: [VOTE] Accumulo 1.6.0-RC4

[Mike Drob]

-1

The good:

* Verified all signatures and checksums.
* Ran continuous ingest with binary artifact + custom built native maps.


The issues, but not enough to vote against:

* Encountered ACCUMULO-2741.
* Encountered ACCUMULO-2742.
* Source artifact missing .gitignore
** This has been discussed, and I'm voting for precedent here. We can agree
to disagree, and if this vote passes then a new precedent will have been
set.


The bad:

* CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD)
** Past discussion here: http://markmail.org/message/ulvovup36uaa2cav
** It seems like we agreed to only include changes from the current major
release line, but that is not 100% clear.

* Missing licence headers:
** README
** conf/examples/crypto/readme.txt
** test/compat/japi-compliance/README
** test/system/continuous/ScaleTest.odp
**
docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg

**
docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf

**
docs/src/main/latex/common/state_diagrams/tablet_states.odg

** docs/src/main/latex/common/state_diagrams/tablet_states.pdf

On Fri, Apr 25, 2014 at 8:35 PM, Christopher  wrote:

> Accumulo Developers,
>
> Please consider the following candidate for Accumulo 1.6.0.
>
> Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
> Branch: 1.6.0-RC4
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
> Source:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
> Binary:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
> (Append ".sha1", ".md5" or ".asc" to download the signature/hash for a
> given artifact.)
>
> All artifacts were built and staged with:
> mvn release:prepare && mvn release:perform
>
> Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
>
> Release notes (in progress):
> http://accumulo.apache.org/release_notes/1.6.0
>
> Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):
>
> https://issues.apache.org/jira/browse/ACCUMULO-1219
> https://issues.apache.org/jira/browse/ACCUMULO-2523
> https://issues.apache.org/jira/browse/ACCUMULO-2569
> https://issues.apache.org/jira/browse/ACCUMULO-2654
> https://issues.apache.org/jira/browse/ACCUMULO-2707
> https://issues.apache.org/jira/browse/ACCUMULO-2713
> https://issues.apache.org/jira/browse/ACCUMULO-2714
> https://issues.apache.org/jira/browse/ACCUMULO-2715
> https://issues.apache.org/jira/browse/ACCUMULO-2716
> https://issues.apache.org/jira/browse/ACCUMULO-2717
> https://issues.apache.org/jira/browse/ACCUMULO-2718
> https://issues.apache.org/jira/browse/ACCUMULO-2720
> https://issues.apache.org/jira/browse/ACCUMULO-2723
> https://issues.apache.org/jira/browse/ACCUMULO-2726
> https://issues.apache.org/jira/browse/ACCUMULO-2728
> https://issues.apache.org/jira/browse/ACCUMULO-2729
> https://issues.apache.org/jira/browse/ACCUMULO-2733
> https://issues.apache.org/jira/browse/ACCUMULO-2734
>
> This vote will remain open for 72 hours (3 days), until Tue, 2014
> April 28 01:00 UTC.
> (That's 9pm EDT on Monday.)
>
> [ ] +1 - I have verified and accept...
> [ ] +0 - I have reservations, but not strong enough to vote against...
> [ ] -1 - Because..., I do not accept...
> ... these artifacts as the 1.6.0 release of Apache Accumulo.
>
> Thanks.
>
> P.S. Hint: download the whole staging repo with
> wget -erobots=off -r -l inf -np -nH
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/
> # note the trailing slash is needed
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>

Re: [VOTE] Accumulo 1.6.0-RC4

[John Vines]

Please change the subject if you're going to change this into a
conversation about when to start votes. This subject is for votes for an RC
candidate.


On Mon, Apr 28, 2014 at 11:30 AM, William Slacum <
wilhelm.von.cl...@accumulo.net> wrote:

> I was concerned about the lack of activity. I don't have a personal need
> for an extension, but I do recall a discussion about Friday RC's
> potentially being problematic in the past, which is why I brought it up.
>
>
> On Mon, Apr 28, 2014 at 11:21 AM, Christopher  wrote:
>
> > I don't know what everyone's schedules are. If the point of a vote was
> > to begin performing testing, I'd say yes, or if this were RC1, I'd say
> > yes (or extended it to 4 days so it's not a surprise). However, since
> > we're already in the RC mindset, having had 3 prior ones already, an
> > RC4 was already expected to be forthcoming. Since I don't think any of
> > the issues since RC3 invalidate the previous testing, and because this
> > is RC4, having gone through several previous candidates, I think a 3
> > day vote starting on Friday is fine. That gives many people an
> > opportunity to examine the release candidate's changes since the last
> > one, whether they do so on a weekend or whether they do so on Monday.
> >
> > I'm not concerned about the lack of initial activity... that's usually
> > the pattern for votes.
> >
> > Do you think you need extra time to evaluate the release candidate? Do
> > we need to discuss an extension?
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> >
> > On Mon, Apr 28, 2014 at 8:24 AM, William Slacum
> >  wrote:
> > > Do you think doing this on a Friday was a good idea? I know that point
> > came
> > > up earlier, and it was possibly due to already discovered issues that
> > would
> > > fail the release, but I think the lack of traffic on here is
> significant.
> > >
> > >
> > > On Fri, Apr 25, 2014 at 8:37 PM, Christopher 
> > wrote:
> > >
> > >> Correction on the vote end date. It's:
> > >> Tue, 2014 April 29 01:00 UTC ... or
> > >> Mon, 2014 April 28 21:00 EDT (9pm)
> > >>
> > >> The initial email had the wrong date (28 instead of 29).
> > >>
> > >> --
> > >> Christopher L Tubbs II
> > >> http://gravatar.com/ctubbsii
> > >>
> > >>
> > >> On Fri, Apr 25, 2014 at 8:35 PM, Christopher 
> > wrote:
> > >> > Accumulo Developers,
> > >> >
> > >> > Please consider the following candidate for Accumulo 1.6.0.
> > >> >
> > >> > Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
> > >> > Branch: 1.6.0-RC4
> > >> >
> > >> > Staging repo:
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
> > >> > Source:
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
> > >> > Binary:
> > >>
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
> > >> > (Append ".sha1", ".md5" or ".asc" to download the signature/hash
> for a
> > >> > given artifact.)
> > >> >
> > >> > All artifacts were built and staged with:
> > >> > mvn release:prepare && mvn release:perform
> > >> >
> > >> > Signing keys available at:
> https://www.apache.org/dist/accumulo/KEYS
> > >> >
> > >> > Release notes (in progress):
> > >> http://accumulo.apache.org/release_notes/1.6.0
> > >> >
> > >> > Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):
> > >> >
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-1219
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2523
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2569
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2654
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2707
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2713
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2714
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2715
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2716
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2717
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2718
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2720
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2723
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2726
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2728
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2729
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2733
> > >> > https://issues.apache.org/jira/browse/ACCUMULO-2734
> > >> >
> > >> > This vote will remain open for 72 hours (3 days), until Tue, 2014
> > >> > April 28 01:00 UTC.
> > >> > (That's 9pm EDT on Monday.)
> > >> >
> > >> > [ ] +1 - I have verified and accept...
> > >> > [ ] +0 - I have reservations, but not strong enough to vote
> against...
> > >> > [ ] -1 - Because..., I do not accept...
> > >> > ... these artifacts as the 1.6.0 release of Apache Accumulo.
> > >> >
> > >> > Thank

Re: [VOTE] Accumulo 1.6.0-RC4

[William Slacum]

I was concerned about the lack of activity. I don't have a personal need
for an extension, but I do recall a discussion about Friday RC's
potentially being problematic in the past, which is why I brought it up.


On Mon, Apr 28, 2014 at 11:21 AM, Christopher  wrote:

> I don't know what everyone's schedules are. If the point of a vote was
> to begin performing testing, I'd say yes, or if this were RC1, I'd say
> yes (or extended it to 4 days so it's not a surprise). However, since
> we're already in the RC mindset, having had 3 prior ones already, an
> RC4 was already expected to be forthcoming. Since I don't think any of
> the issues since RC3 invalidate the previous testing, and because this
> is RC4, having gone through several previous candidates, I think a 3
> day vote starting on Friday is fine. That gives many people an
> opportunity to examine the release candidate's changes since the last
> one, whether they do so on a weekend or whether they do so on Monday.
>
> I'm not concerned about the lack of initial activity... that's usually
> the pattern for votes.
>
> Do you think you need extra time to evaluate the release candidate? Do
> we need to discuss an extension?
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Mon, Apr 28, 2014 at 8:24 AM, William Slacum
>  wrote:
> > Do you think doing this on a Friday was a good idea? I know that point
> came
> > up earlier, and it was possibly due to already discovered issues that
> would
> > fail the release, but I think the lack of traffic on here is significant.
> >
> >
> > On Fri, Apr 25, 2014 at 8:37 PM, Christopher 
> wrote:
> >
> >> Correction on the vote end date. It's:
> >> Tue, 2014 April 29 01:00 UTC ... or
> >> Mon, 2014 April 28 21:00 EDT (9pm)
> >>
> >> The initial email had the wrong date (28 instead of 29).
> >>
> >> --
> >> Christopher L Tubbs II
> >> http://gravatar.com/ctubbsii
> >>
> >>
> >> On Fri, Apr 25, 2014 at 8:35 PM, Christopher 
> wrote:
> >> > Accumulo Developers,
> >> >
> >> > Please consider the following candidate for Accumulo 1.6.0.
> >> >
> >> > Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
> >> > Branch: 1.6.0-RC4
> >> >
> >> > Staging repo:
> >>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
> >> > Source:
> >>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
> >> > Binary:
> >>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
> >> > (Append ".sha1", ".md5" or ".asc" to download the signature/hash for a
> >> > given artifact.)
> >> >
> >> > All artifacts were built and staged with:
> >> > mvn release:prepare && mvn release:perform
> >> >
> >> > Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
> >> >
> >> > Release notes (in progress):
> >> http://accumulo.apache.org/release_notes/1.6.0
> >> >
> >> > Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):
> >> >
> >> > https://issues.apache.org/jira/browse/ACCUMULO-1219
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2523
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2569
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2654
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2707
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2713
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2714
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2715
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2716
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2717
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2718
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2720
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2723
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2726
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2728
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2729
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2733
> >> > https://issues.apache.org/jira/browse/ACCUMULO-2734
> >> >
> >> > This vote will remain open for 72 hours (3 days), until Tue, 2014
> >> > April 28 01:00 UTC.
> >> > (That's 9pm EDT on Monday.)
> >> >
> >> > [ ] +1 - I have verified and accept...
> >> > [ ] +0 - I have reservations, but not strong enough to vote against...
> >> > [ ] -1 - Because..., I do not accept...
> >> > ... these artifacts as the 1.6.0 release of Apache Accumulo.
> >> >
> >> > Thanks.
> >> >
> >> > P.S. Hint: download the whole staging repo with
> >> > wget -erobots=off -r -l inf -np -nH
> >> >
> >>
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/
> >> > # note the trailing slash is needed
> >> >
> >> > --
> >> > Christopher L Tubbs II
> >> > http://gravatar.com/ctubbsii
> >>
>

Re: [VOTE] Accumulo 1.6.0-RC4

[Christopher]

I don't know what everyone's schedules are. If the point of a vote was
to begin performing testing, I'd say yes, or if this were RC1, I'd say
yes (or extended it to 4 days so it's not a surprise). However, since
we're already in the RC mindset, having had 3 prior ones already, an
RC4 was already expected to be forthcoming. Since I don't think any of
the issues since RC3 invalidate the previous testing, and because this
is RC4, having gone through several previous candidates, I think a 3
day vote starting on Friday is fine. That gives many people an
opportunity to examine the release candidate's changes since the last
one, whether they do so on a weekend or whether they do so on Monday.

I'm not concerned about the lack of initial activity... that's usually
the pattern for votes.

Do you think you need extra time to evaluate the release candidate? Do
we need to discuss an extension?

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Mon, Apr 28, 2014 at 8:24 AM, William Slacum
 wrote:
> Do you think doing this on a Friday was a good idea? I know that point came
> up earlier, and it was possibly due to already discovered issues that would
> fail the release, but I think the lack of traffic on here is significant.
>
>
> On Fri, Apr 25, 2014 at 8:37 PM, Christopher  wrote:
>
>> Correction on the vote end date. It's:
>> Tue, 2014 April 29 01:00 UTC ... or
>> Mon, 2014 April 28 21:00 EDT (9pm)
>>
>> The initial email had the wrong date (28 instead of 29).
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Fri, Apr 25, 2014 at 8:35 PM, Christopher  wrote:
>> > Accumulo Developers,
>> >
>> > Please consider the following candidate for Accumulo 1.6.0.
>> >
>> > Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
>> > Branch: 1.6.0-RC4
>> >
>> > Staging repo:
>> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
>> > Source:
>> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
>> > Binary:
>> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
>> > (Append ".sha1", ".md5" or ".asc" to download the signature/hash for a
>> > given artifact.)
>> >
>> > All artifacts were built and staged with:
>> > mvn release:prepare && mvn release:perform
>> >
>> > Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
>> >
>> > Release notes (in progress):
>> http://accumulo.apache.org/release_notes/1.6.0
>> >
>> > Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):
>> >
>> > https://issues.apache.org/jira/browse/ACCUMULO-1219
>> > https://issues.apache.org/jira/browse/ACCUMULO-2523
>> > https://issues.apache.org/jira/browse/ACCUMULO-2569
>> > https://issues.apache.org/jira/browse/ACCUMULO-2654
>> > https://issues.apache.org/jira/browse/ACCUMULO-2707
>> > https://issues.apache.org/jira/browse/ACCUMULO-2713
>> > https://issues.apache.org/jira/browse/ACCUMULO-2714
>> > https://issues.apache.org/jira/browse/ACCUMULO-2715
>> > https://issues.apache.org/jira/browse/ACCUMULO-2716
>> > https://issues.apache.org/jira/browse/ACCUMULO-2717
>> > https://issues.apache.org/jira/browse/ACCUMULO-2718
>> > https://issues.apache.org/jira/browse/ACCUMULO-2720
>> > https://issues.apache.org/jira/browse/ACCUMULO-2723
>> > https://issues.apache.org/jira/browse/ACCUMULO-2726
>> > https://issues.apache.org/jira/browse/ACCUMULO-2728
>> > https://issues.apache.org/jira/browse/ACCUMULO-2729
>> > https://issues.apache.org/jira/browse/ACCUMULO-2733
>> > https://issues.apache.org/jira/browse/ACCUMULO-2734
>> >
>> > This vote will remain open for 72 hours (3 days), until Tue, 2014
>> > April 28 01:00 UTC.
>> > (That's 9pm EDT on Monday.)
>> >
>> > [ ] +1 - I have verified and accept...
>> > [ ] +0 - I have reservations, but not strong enough to vote against...
>> > [ ] -1 - Because..., I do not accept...
>> > ... these artifacts as the 1.6.0 release of Apache Accumulo.
>> >
>> > Thanks.
>> >
>> > P.S. Hint: download the whole staging repo with
>> > wget -erobots=off -r -l inf -np -nH
>> >
>> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/
>> > # note the trailing slash is needed
>> >
>> > --
>> > Christopher L Tubbs II
>> > http://gravatar.com/ctubbsii
>>

Re: [VOTE] Accumulo 1.6.0-RC4

[Mike Drob]

We also have a tendency to vote at the last minute anyway, regardless of
weekend or weekday. I hope that's because everybody is busy running tests.
:)


On Mon, Apr 28, 2014 at 11:04 AM, Sean Busbey  wrote:

> I think Friday was fine. I know I've just been silent due to recovery time
> from the surge of activity around making sure RC4 would be ready. I suspect
> it might be the same for others.
>
>
> On Mon, Apr 28, 2014 at 7:24 AM, William Slacum <
> wilhelm.von.cl...@accumulo.net> wrote:
>
> > Do you think doing this on a Friday was a good idea? I know that point
> came
> > up earlier, and it was possibly due to already discovered issues that
> would
> > fail the release, but I think the lack of traffic on here is significant.
> >
> >
> > On Fri, Apr 25, 2014 at 8:37 PM, Christopher 
> wrote:
> >
> > > Correction on the vote end date. It's:
> > > Tue, 2014 April 29 01:00 UTC ... or
> > > Mon, 2014 April 28 21:00 EDT (9pm)
> > >
> > > The initial email had the wrong date (28 instead of 29).
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> > >
> > > On Fri, Apr 25, 2014 at 8:35 PM, Christopher 
> > wrote:
> > > > Accumulo Developers,
> > > >
> > > > Please consider the following candidate for Accumulo 1.6.0.
> > > >
> > > > Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
> > > > Branch: 1.6.0-RC4
> > > >
> > > > Staging repo:
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
> > > > Source:
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
> > > > Binary:
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
> > > > (Append ".sha1", ".md5" or ".asc" to download the signature/hash for
> a
> > > > given artifact.)
> > > >
> > > > All artifacts were built and staged with:
> > > > mvn release:prepare && mvn release:perform
> > > >
> > > > Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
> > > >
> > > > Release notes (in progress):
> > > http://accumulo.apache.org/release_notes/1.6.0
> > > >
> > > > Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):
> > > >
> > > > https://issues.apache.org/jira/browse/ACCUMULO-1219
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2523
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2569
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2654
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2707
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2713
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2714
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2715
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2716
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2717
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2718
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2720
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2723
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2726
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2728
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2729
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2733
> > > > https://issues.apache.org/jira/browse/ACCUMULO-2734
> > > >
> > > > This vote will remain open for 72 hours (3 days), until Tue, 2014
> > > > April 28 01:00 UTC.
> > > > (That's 9pm EDT on Monday.)
> > > >
> > > > [ ] +1 - I have verified and accept...
> > > > [ ] +0 - I have reservations, but not strong enough to vote
> against...
> > > > [ ] -1 - Because..., I do not accept...
> > > > ... these artifacts as the 1.6.0 release of Apache Accumulo.
> > > >
> > > > Thanks.
> > > >
> > > > P.S. Hint: download the whole staging repo with
> > > > wget -erobots=off -r -l inf -np -nH
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/
> > > > # note the trailing slash is needed
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > >
> >
>
>
>
> --
> Sean
>

Re: [VOTE] Accumulo 1.6.0-RC4

[Sean Busbey]

I think Friday was fine. I know I've just been silent due to recovery time
from the surge of activity around making sure RC4 would be ready. I suspect
it might be the same for others.


On Mon, Apr 28, 2014 at 7:24 AM, William Slacum <
wilhelm.von.cl...@accumulo.net> wrote:

> Do you think doing this on a Friday was a good idea? I know that point came
> up earlier, and it was possibly due to already discovered issues that would
> fail the release, but I think the lack of traffic on here is significant.
>
>
> On Fri, Apr 25, 2014 at 8:37 PM, Christopher  wrote:
>
> > Correction on the vote end date. It's:
> > Tue, 2014 April 29 01:00 UTC ... or
> > Mon, 2014 April 28 21:00 EDT (9pm)
> >
> > The initial email had the wrong date (28 instead of 29).
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> >
> > On Fri, Apr 25, 2014 at 8:35 PM, Christopher 
> wrote:
> > > Accumulo Developers,
> > >
> > > Please consider the following candidate for Accumulo 1.6.0.
> > >
> > > Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
> > > Branch: 1.6.0-RC4
> > >
> > > Staging repo:
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
> > > Source:
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
> > > Binary:
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
> > > (Append ".sha1", ".md5" or ".asc" to download the signature/hash for a
> > > given artifact.)
> > >
> > > All artifacts were built and staged with:
> > > mvn release:prepare && mvn release:perform
> > >
> > > Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
> > >
> > > Release notes (in progress):
> > http://accumulo.apache.org/release_notes/1.6.0
> > >
> > > Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):
> > >
> > > https://issues.apache.org/jira/browse/ACCUMULO-1219
> > > https://issues.apache.org/jira/browse/ACCUMULO-2523
> > > https://issues.apache.org/jira/browse/ACCUMULO-2569
> > > https://issues.apache.org/jira/browse/ACCUMULO-2654
> > > https://issues.apache.org/jira/browse/ACCUMULO-2707
> > > https://issues.apache.org/jira/browse/ACCUMULO-2713
> > > https://issues.apache.org/jira/browse/ACCUMULO-2714
> > > https://issues.apache.org/jira/browse/ACCUMULO-2715
> > > https://issues.apache.org/jira/browse/ACCUMULO-2716
> > > https://issues.apache.org/jira/browse/ACCUMULO-2717
> > > https://issues.apache.org/jira/browse/ACCUMULO-2718
> > > https://issues.apache.org/jira/browse/ACCUMULO-2720
> > > https://issues.apache.org/jira/browse/ACCUMULO-2723
> > > https://issues.apache.org/jira/browse/ACCUMULO-2726
> > > https://issues.apache.org/jira/browse/ACCUMULO-2728
> > > https://issues.apache.org/jira/browse/ACCUMULO-2729
> > > https://issues.apache.org/jira/browse/ACCUMULO-2733
> > > https://issues.apache.org/jira/browse/ACCUMULO-2734
> > >
> > > This vote will remain open for 72 hours (3 days), until Tue, 2014
> > > April 28 01:00 UTC.
> > > (That's 9pm EDT on Monday.)
> > >
> > > [ ] +1 - I have verified and accept...
> > > [ ] +0 - I have reservations, but not strong enough to vote against...
> > > [ ] -1 - Because..., I do not accept...
> > > ... these artifacts as the 1.6.0 release of Apache Accumulo.
> > >
> > > Thanks.
> > >
> > > P.S. Hint: download the whole staging repo with
> > > wget -erobots=off -r -l inf -np -nH
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/
> > > # note the trailing slash is needed
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> >
>



-- 
Sean

Re: Beyond 1.6

[Bill Havanki]

Thanks for setting out the discussion, Josh. I agree with you on all of
these issues. My thoughts:

* +1 on "2.0.0". We absolutely could use the extra "room" for versioning.

* The closer we stick to semantic versioning [1] (or some other well-known
versioning spec ... are there any?), the better. a) Versioning is an
encoded message to our users on what changed, and using a common language
is best for that (with limited tailoring as needed). b) Lots of other
projects' experiences are baked into such a standard, like a design
pattern, and we can use that.

* I think we'll naturally get more frequent releases by adopting a more
flexible versioning scheme, adjusting CM practices to match, and improving
and refining the test framework. So, release timing won't be a big deal -
we'll have the power to pick the cadence we like. Therefore, I'd see
release timing as something to define later on in this process.

I suggest the first step is to define the Accumulo versioning scheme,
starting at 2.0.0. The definition can be driven by all the compatibility
concerns, so those need to be enumerated and analyzed for how they evolve
and how that should reflect in versioning.

Bill H

[1] http://semver.org/


On Thu, Apr 24, 2014 at 11:45 AM, Josh Elser  wrote:

> All,
>
> I'd like to start the discussion about where we go after we release 1.6.0.
> We have a lot of great ideas that people have outlined that together, I
> think, would make a really compelling version of Accumulo.
>
> Besides a set of new features/changes, we've also talked about changing
> how we version the software in such a way that would better align with how
> we want to support it and the  guarantees we want to provide. Some of these
> will require additional discussion, but I believe there are a few things we
> could knock out ahead of time that will help in these later discussions
> (especially those regarding API, data and wire compatitbility).
>
> The easy one: is everyone happy with calling the next "major" version
> after 1.6.0, "2.0.0"? I believe that reclaiming that extra digit in our
> current version string (the "1" in 1.6.0) will help alleviate many of the
> problems that we've been facing in where code is "allowed" to go.
>
> Going a little deeper, I think we can also agree to some *general*
> guidelines about what these numbers mean, following what semantic
> versioning generally outlines based on what we've been trying to follow to
> date. The major (most-significant) number refers to releases in which very
> impactful changes were made to the codebase. The minor (middle) number
> refers to changes/improvements which are lesser in nature, but do not
> represent a major shift in how to use or administer Accumulo. The bugix
> (least-significant) number should *only* contain the least impactful change
> which address some breakage in the code.
>
>  - an important point that needs clarification is how we draw the line
> between which non-breaking changes can be put in a minor release and which
> must be introduced in a major release.
>
> Bugfix versions should not make any compatibility changes at all - fix the
> bug as it stands. Minor versions can introduce additions to the public API,
> storage or wire implementations, but they should be done in a backwards
> compatible way. Major versions can remove deprecated public API calls. Data
> compatibility can be met with some upgrade process instead of full
> compatibility with the previous versions. Wire compatibility does not need
> to be guaranteed across major versions if this is not possible.
>
> Then, we can target major releases ~yearly, minor releases every few
> months, and bugfix releases in order of weeks based on severity. I would
> also suggest that we reduce our testing burden for bugfixes to be more
> focused on verifying that the bugs have been identified in tests and
> verified as fixed.
>
> This got a lot longer than I wanted, so I'm sorry for that. Please feel
> free to suggest pruning to this list so we can have a discussion that nets
> some actual results.
>
> - Josh
>



-- 
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283

Re: [VOTE] Accumulo 1.6.0-RC4

[William Slacum]

Do you think doing this on a Friday was a good idea? I know that point came
up earlier, and it was possibly due to already discovered issues that would
fail the release, but I think the lack of traffic on here is significant.


On Fri, Apr 25, 2014 at 8:37 PM, Christopher  wrote:

> Correction on the vote end date. It's:
> Tue, 2014 April 29 01:00 UTC ... or
> Mon, 2014 April 28 21:00 EDT (9pm)
>
> The initial email had the wrong date (28 instead of 29).
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Fri, Apr 25, 2014 at 8:35 PM, Christopher  wrote:
> > Accumulo Developers,
> >
> > Please consider the following candidate for Accumulo 1.6.0.
> >
> > Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3
> > Branch: 1.6.0-RC4
> >
> > Staging repo:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010
> > Source:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz
> > Binary:
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-bin.tar.gz
> > (Append ".sha1", ".md5" or ".asc" to download the signature/hash for a
> > given artifact.)
> >
> > All artifacts were built and staged with:
> > mvn release:prepare && mvn release:perform
> >
> > Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
> >
> > Release notes (in progress):
> http://accumulo.apache.org/release_notes/1.6.0
> >
> > Changes since RC3 (`git log 5678e51..origin/1.6.0-RC4`):
> >
> > https://issues.apache.org/jira/browse/ACCUMULO-1219
> > https://issues.apache.org/jira/browse/ACCUMULO-2523
> > https://issues.apache.org/jira/browse/ACCUMULO-2569
> > https://issues.apache.org/jira/browse/ACCUMULO-2654
> > https://issues.apache.org/jira/browse/ACCUMULO-2707
> > https://issues.apache.org/jira/browse/ACCUMULO-2713
> > https://issues.apache.org/jira/browse/ACCUMULO-2714
> > https://issues.apache.org/jira/browse/ACCUMULO-2715
> > https://issues.apache.org/jira/browse/ACCUMULO-2716
> > https://issues.apache.org/jira/browse/ACCUMULO-2717
> > https://issues.apache.org/jira/browse/ACCUMULO-2718
> > https://issues.apache.org/jira/browse/ACCUMULO-2720
> > https://issues.apache.org/jira/browse/ACCUMULO-2723
> > https://issues.apache.org/jira/browse/ACCUMULO-2726
> > https://issues.apache.org/jira/browse/ACCUMULO-2728
> > https://issues.apache.org/jira/browse/ACCUMULO-2729
> > https://issues.apache.org/jira/browse/ACCUMULO-2733
> > https://issues.apache.org/jira/browse/ACCUMULO-2734
> >
> > This vote will remain open for 72 hours (3 days), until Tue, 2014
> > April 28 01:00 UTC.
> > (That's 9pm EDT on Monday.)
> >
> > [ ] +1 - I have verified and accept...
> > [ ] +0 - I have reservations, but not strong enough to vote against...
> > [ ] -1 - Because..., I do not accept...
> > ... these artifacts as the 1.6.0 release of Apache Accumulo.
> >
> > Thanks.
> >
> > P.S. Hint: download the whole staging repo with
> > wget -erobots=off -r -l inf -np -nH
> >
> https://repository.apache.org/content/repositories/orgapacheaccumulo-1010/
> > # note the trailing slash is needed
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
>