Re: [VOTE] Accumulo Blog
+1 On Sun, Apr 13, 2014 at 8:11 PM, dlmar...@comcast.net wrote: I have reviewed the feedback from the proposal thread and consolidated it into a set of guidelines for an Accumulo Blog. In accordance with the bylaws this vote will require Lazy Approval to pass and will remain open for 3 business days. I'll tally the votes on Thursday morning. 1. The blog will be hosted on the Apache Blogs site[1]. 2. The blog will be set up using the instructions at [2] to enable public preview. 3. Proposed blog content will be posted in full-text or link form to the dev mailing list. 4. Blog content requires Lazy Approval votes that are open for at least 3 days. 5. Content may be cross-posted from other sites provided that the content is more than just a link to the other site. The full text of the original article is preferred. 6. Content may be cross-posted to other sites provided that there is a link back to the Accumulo blog site. [1] http://blogs.apache.org/ [2] http://www.apache.org/dev/project-blogs -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
Re: [VOTE] Accumulo Blog
+1 On Mon, Apr 14, 2014 at 7:42 AM, Bill Havanki bhava...@clouderagovt.comwrote: +1 On Sun, Apr 13, 2014 at 8:11 PM, dlmar...@comcast.net wrote: I have reviewed the feedback from the proposal thread and consolidated it into a set of guidelines for an Accumulo Blog. In accordance with the bylaws this vote will require Lazy Approval to pass and will remain open for 3 business days. I'll tally the votes on Thursday morning. 1. The blog will be hosted on the Apache Blogs site[1]. 2. The blog will be set up using the instructions at [2] to enable public preview. 3. Proposed blog content will be posted in full-text or link form to the dev mailing list. 4. Blog content requires Lazy Approval votes that are open for at least 3 days. 5. Content may be cross-posted from other sites provided that the content is more than just a link to the other site. The full text of the original article is preferred. 6. Content may be cross-posted to other sites provided that there is a link back to the Accumulo blog site. [1] http://blogs.apache.org/ [2] http://www.apache.org/dev/project-blogs -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283 -- Sean
Re: [VOTE] Define CTR in Bylaws
This vote passes with 6 +1 votes from PMC members and no other votes. On Mon, Apr 7, 2014 at 7:11 AM, Billie Rinaldi bil...@apache.org wrote: Please vote on applying the following changes to the Accumulo bylaws ( http://accumulo.apache.org/bylaws.html). If the Code Change action has been removed, it will be reintroduced along with these changes. This vote will remain open for 7 days and requires majority approval to pass. [ ] +1 - I approve of these proposed bylaw changes and accept them for the Apache Accumulo project. [ ] +0 - I neither approve nor disapprove of these proposed bylaw changes, but accept them for the Apache Accumulo project. [ ] -1 - I do not approve of these proposed bylaw changes and do not accept them for the Apache Accumulo project because... Index: bylaws.mdtext == = --- bylaws.mdtext(revision 1584734) +++ bylaws.mdtext(working copy) @@ -125,8 +125,15 @@ All participants in the Accumulo project are encouraged to vote. For technical decisions, only the votes of active committers are binding. Non-binding votes are still useful for those with binding votes to understand the perception of an action across the wider Accumulo community. For PMC decisions, only the votes of active PMC members are binding. -Voting can also be applied to changes to the Accumulo codebase. Please refer to the Accumulo commit and review standard for details. +See the [voting page](http://accumulo.apache.org/governance/voting.html) for more details on the mechanics of voting. +a name=CTR/a +## Commit Then Review (CTR) + +Voting can also be applied to changes to the Accumulo codebase. Under the Commit Then Review policy, committers can make changes to the codebase without seeking approval beforehand, and the changes are assumed to be approved unless an objection is raised. Only if an objection is raised must a vote take place on the code change. + +For some code changes, committers may wish to get feedback from the community before making the change. It is acceptable for a committer to seek approval before making a change if they so desire. + ## Approvals These are the types of approvals that can be sought. Different actions require different types of approvals. @@ -139,7 +146,7 @@ trtdMajority Approval/td tdA majority approval vote passes with 3 binding +1 votes and more binding +1 votes than -1 votes./td trtdLazy Approval (or Lazy Consensus)/td -tdAn action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either majority approval or consensus approval must be obtained./td +tdAn action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either majority approval or consensus approval must be obtained. Lazy Approval can be either emstated/em or emassumed/em, as detailed on the [lazy consensus page](http://accumulo.apache.org/governance/lazyConsensus.html) ./td /table ## Vetoes @@ -152,6 +159,8 @@ This section describes the various actions which are undertaken within the project, the corresponding approval required for that action and those who have binding votes over the action. It also specifies the minimum length of time that a vote must remain open, measured in days. In general, votes should not be called at times when it is known that interested members of the project will be unavailable. +For Code Change actions, a committer may choose to employ assumed or stated Lazy Approval under the [CTR](#CTR) policy. Assumed Lazy Approval has no minimum length of time before the change can be made. + table trthAction/th thDescription/th
Re: [VOTE] Accumulo Blog
+1 On Sun, Apr 13, 2014 at 8:11 PM, dlmar...@comcast.net wrote: I have reviewed the feedback from the proposal thread and consolidated it into a set of guidelines for an Accumulo Blog. In accordance with the bylaws this vote will require Lazy Approval to pass and will remain open for 3 business days. I'll tally the votes on Thursday morning. 1. The blog will be hosted on the Apache Blogs site[1]. 2. The blog will be set up using the instructions at [2] to enable public preview. 3. Proposed blog content will be posted in full-text or link form to the dev mailing list. 4. Blog content requires Lazy Approval votes that are open for at least 3 days. 5. Content may be cross-posted from other sites provided that the content is more than just a link to the other site. The full text of the original article is preferred. 6. Content may be cross-posted to other sites provided that there is a link back to the Accumulo blog site. [1] http://blogs.apache.org/ [2] http://www.apache.org/dev/project-blogs
Re: [VOTE] Accumulo Blog
+1 On 4/13/14, 8:11 PM, dlmar...@comcast.net wrote: I have reviewed the feedback from the proposal thread and consolidated it into a set of guidelines for an Accumulo Blog. In accordance with the bylaws this vote will require Lazy Approval to pass and will remain open for 3 business days. I'll tally the votes on Thursday morning. 1. The blog will be hosted on the Apache Blogs site[1]. 2. The blog will be set up using the instructions at [2] to enable public preview. 3. Proposed blog content will be posted in full-text or link form to the dev mailing list. 4. Blog content requires Lazy Approval votes that are open for at least 3 days. 5. Content may be cross-posted from other sites provided that the content is more than just a link to the other site. The full text of the original article is preferred. 6. Content may be cross-posted to other sites provided that there is a link back to the Accumulo blog site. [1] http://blogs.apache.org/ [2] http://www.apache.org/dev/project-blogs
Re: [VOTE] Accumulo Blog
+1 (non-binding) -- Joey Echeverria Chief Architect Cloudera Government Solutions On Mon, Apr 14, 2014 at 11:16 AM, Josh Elser josh.el...@gmail.com wrote: +1 On 4/13/14, 8:11 PM, dlmar...@comcast.net wrote: I have reviewed the feedback from the proposal thread and consolidated it into a set of guidelines for an Accumulo Blog. In accordance with the bylaws this vote will require Lazy Approval to pass and will remain open for 3 business days. I'll tally the votes on Thursday morning. 1. The blog will be hosted on the Apache Blogs site[1]. 2. The blog will be set up using the instructions at [2] to enable public preview. 3. Proposed blog content will be posted in full-text or link form to the dev mailing list. 4. Blog content requires Lazy Approval votes that are open for at least 3 days. 5. Content may be cross-posted from other sites provided that the content is more than just a link to the other site. The full text of the original article is preferred. 6. Content may be cross-posted to other sites provided that there is a link back to the Accumulo blog site. [1] http://blogs.apache.org/ [2] http://www.apache.org/dev/project-blogs
Re: [VOTE] Define CTR in Bylaws
I committed the change to the bylaws. Note that I also had to convert the lazy consensus link to standard html instead of markdown since it was in a table. On Mon, Apr 14, 2014 at 8:04 AM, Billie Rinaldi billie.rina...@gmail.comwrote: This vote passes with 6 +1 votes from PMC members and no other votes. On Mon, Apr 7, 2014 at 7:11 AM, Billie Rinaldi bil...@apache.org wrote: Please vote on applying the following changes to the Accumulo bylaws ( http://accumulo.apache.org/bylaws.html). If the Code Change action has been removed, it will be reintroduced along with these changes. This vote will remain open for 7 days and requires majority approval to pass. [ ] +1 - I approve of these proposed bylaw changes and accept them for the Apache Accumulo project. [ ] +0 - I neither approve nor disapprove of these proposed bylaw changes, but accept them for the Apache Accumulo project. [ ] -1 - I do not approve of these proposed bylaw changes and do not accept them for the Apache Accumulo project because... Index: bylaws.mdtext == = --- bylaws.mdtext(revision 1584734) +++ bylaws.mdtext(working copy) @@ -125,8 +125,15 @@ All participants in the Accumulo project are encouraged to vote. For technical decisions, only the votes of active committers are binding. Non-binding votes are still useful for those with binding votes to understand the perception of an action across the wider Accumulo community. For PMC decisions, only the votes of active PMC members are binding. -Voting can also be applied to changes to the Accumulo codebase. Please refer to the Accumulo commit and review standard for details. +See the [voting page](http://accumulo.apache.org/governance/voting.html) for more details on the mechanics of voting. +a name=CTR/a +## Commit Then Review (CTR) + +Voting can also be applied to changes to the Accumulo codebase. Under the Commit Then Review policy, committers can make changes to the codebase without seeking approval beforehand, and the changes are assumed to be approved unless an objection is raised. Only if an objection is raised must a vote take place on the code change. + +For some code changes, committers may wish to get feedback from the community before making the change. It is acceptable for a committer to seek approval before making a change if they so desire. + ## Approvals These are the types of approvals that can be sought. Different actions require different types of approvals. @@ -139,7 +146,7 @@ trtdMajority Approval/td tdA majority approval vote passes with 3 binding +1 votes and more binding +1 votes than -1 votes./td trtdLazy Approval (or Lazy Consensus)/td -tdAn action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either majority approval or consensus approval must be obtained./td +tdAn action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either majority approval or consensus approval must be obtained. Lazy Approval can be either emstated/em or emassumed/em, as detailed on the [lazy consensus page](http://accumulo.apache.org/governance/lazyConsensus.html) ./td /table ## Vetoes @@ -152,6 +159,8 @@ This section describes the various actions which are undertaken within the project, the corresponding approval required for that action and those who have binding votes over the action. It also specifies the minimum length of time that a vote must remain open, measured in days. In general, votes should not be called at times when it is known that interested members of the project will be unavailable. +For Code Change actions, a committer may choose to employ assumed or stated Lazy Approval under the [CTR](#CTR) policy. Assumed Lazy Approval has no minimum length of time before the change can be made. + table trthAction/th thDescription/th
Re: [VOTE] Define CTR in Bylaws
Should the bylaws now be version 2? On Mon, Apr 14, 2014 at 12:21 PM, Billie Rinaldi billie.rina...@gmail.comwrote: I committed the change to the bylaws. Note that I also had to convert the lazy consensus link to standard html instead of markdown since it was in a table. On Mon, Apr 14, 2014 at 8:04 AM, Billie Rinaldi billie.rina...@gmail.com wrote: This vote passes with 6 +1 votes from PMC members and no other votes. On Mon, Apr 7, 2014 at 7:11 AM, Billie Rinaldi bil...@apache.org wrote: Please vote on applying the following changes to the Accumulo bylaws ( http://accumulo.apache.org/bylaws.html). If the Code Change action has been removed, it will be reintroduced along with these changes. This vote will remain open for 7 days and requires majority approval to pass. [ ] +1 - I approve of these proposed bylaw changes and accept them for the Apache Accumulo project. [ ] +0 - I neither approve nor disapprove of these proposed bylaw changes, but accept them for the Apache Accumulo project. [ ] -1 - I do not approve of these proposed bylaw changes and do not accept them for the Apache Accumulo project because... Index: bylaws.mdtext == = --- bylaws.mdtext(revision 1584734) +++ bylaws.mdtext(working copy) @@ -125,8 +125,15 @@ All participants in the Accumulo project are encouraged to vote. For technical decisions, only the votes of active committers are binding. Non-binding votes are still useful for those with binding votes to understand the perception of an action across the wider Accumulo community. For PMC decisions, only the votes of active PMC members are binding. -Voting can also be applied to changes to the Accumulo codebase. Please refer to the Accumulo commit and review standard for details. +See the [voting page]( http://accumulo.apache.org/governance/voting.html) for more details on the mechanics of voting. +a name=CTR/a +## Commit Then Review (CTR) + +Voting can also be applied to changes to the Accumulo codebase. Under the Commit Then Review policy, committers can make changes to the codebase without seeking approval beforehand, and the changes are assumed to be approved unless an objection is raised. Only if an objection is raised must a vote take place on the code change. + +For some code changes, committers may wish to get feedback from the community before making the change. It is acceptable for a committer to seek approval before making a change if they so desire. + ## Approvals These are the types of approvals that can be sought. Different actions require different types of approvals. @@ -139,7 +146,7 @@ trtdMajority Approval/td tdA majority approval vote passes with 3 binding +1 votes and more binding +1 votes than -1 votes./td trtdLazy Approval (or Lazy Consensus)/td -tdAn action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either majority approval or consensus approval must be obtained./td +tdAn action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either majority approval or consensus approval must be obtained. Lazy Approval can be either emstated/em or emassumed/em, as detailed on the [lazy consensus page]( http://accumulo.apache.org/governance/lazyConsensus.html) ./td /table ## Vetoes @@ -152,6 +159,8 @@ This section describes the various actions which are undertaken within the project, the corresponding approval required for that action and those who have binding votes over the action. It also specifies the minimum length of time that a vote must remain open, measured in days. In general, votes should not be called at times when it is known that interested members of the project will be unavailable. +For Code Change actions, a committer may choose to employ assumed or stated Lazy Approval under the [CTR](#CTR) policy. Assumed Lazy Approval has no minimum length of time before the change can be made. + table trthAction/th thDescription/th -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
Re: [VOTE] Define CTR in Bylaws
Good point. I've fixed it. On Mon, Apr 14, 2014 at 10:10 AM, Bill Havanki bhava...@clouderagovt.comwrote: Should the bylaws now be version 2? On Mon, Apr 14, 2014 at 12:21 PM, Billie Rinaldi billie.rina...@gmail.comwrote: I committed the change to the bylaws. Note that I also had to convert the lazy consensus link to standard html instead of markdown since it was in a table. On Mon, Apr 14, 2014 at 8:04 AM, Billie Rinaldi billie.rina...@gmail.com wrote: This vote passes with 6 +1 votes from PMC members and no other votes. On Mon, Apr 7, 2014 at 7:11 AM, Billie Rinaldi bil...@apache.org wrote: Please vote on applying the following changes to the Accumulo bylaws ( http://accumulo.apache.org/bylaws.html). If the Code Change action has been removed, it will be reintroduced along with these changes. This vote will remain open for 7 days and requires majority approval to pass. [ ] +1 - I approve of these proposed bylaw changes and accept them for the Apache Accumulo project. [ ] +0 - I neither approve nor disapprove of these proposed bylaw changes, but accept them for the Apache Accumulo project. [ ] -1 - I do not approve of these proposed bylaw changes and do not accept them for the Apache Accumulo project because... Index: bylaws.mdtext == = --- bylaws.mdtext(revision 1584734) +++ bylaws.mdtext(working copy) @@ -125,8 +125,15 @@ All participants in the Accumulo project are encouraged to vote. For technical decisions, only the votes of active committers are binding. Non-binding votes are still useful for those with binding votes to understand the perception of an action across the wider Accumulo community. For PMC decisions, only the votes of active PMC members are binding. -Voting can also be applied to changes to the Accumulo codebase. Please refer to the Accumulo commit and review standard for details. +See the [voting page]( http://accumulo.apache.org/governance/voting.html) for more details on the mechanics of voting. +a name=CTR/a +## Commit Then Review (CTR) + +Voting can also be applied to changes to the Accumulo codebase. Under the Commit Then Review policy, committers can make changes to the codebase without seeking approval beforehand, and the changes are assumed to be approved unless an objection is raised. Only if an objection is raised must a vote take place on the code change. + +For some code changes, committers may wish to get feedback from the community before making the change. It is acceptable for a committer to seek approval before making a change if they so desire. + ## Approvals These are the types of approvals that can be sought. Different actions require different types of approvals. @@ -139,7 +146,7 @@ trtdMajority Approval/td tdA majority approval vote passes with 3 binding +1 votes and more binding +1 votes than -1 votes./td trtdLazy Approval (or Lazy Consensus)/td -tdAn action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either majority approval or consensus approval must be obtained./td +tdAn action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either majority approval or consensus approval must be obtained. Lazy Approval can be either emstated/em or emassumed/em, as detailed on the [lazy consensus page]( http://accumulo.apache.org/governance/lazyConsensus.html) ./td /table ## Vetoes @@ -152,6 +159,8 @@ This section describes the various actions which are undertaken within the project, the corresponding approval required for that action and those who have binding votes over the action. It also specifies the minimum length of time that a vote must remain open, measured in days. In general, votes should not be called at times when it is known that interested members of the project will be unavailable. +For Code Change actions, a committer may choose to employ assumed or stated Lazy Approval under the [CTR](#CTR) policy. Assumed Lazy Approval has no minimum length of time before the change can be made. + table trthAction/th thDescription/th -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
Re: [VOTE] Accumulo Blog
+1 On Mon, Apr 14, 2014 at 11:18 AM, Joey Echeverria j...@clouderagovt.comwrote: +1 (non-binding) -- Joey Echeverria Chief Architect Cloudera Government Solutions On Mon, Apr 14, 2014 at 11:16 AM, Josh Elser josh.el...@gmail.com wrote: +1 On 4/13/14, 8:11 PM, dlmar...@comcast.net wrote: I have reviewed the feedback from the proposal thread and consolidated it into a set of guidelines for an Accumulo Blog. In accordance with the bylaws this vote will require Lazy Approval to pass and will remain open for 3 business days. I'll tally the votes on Thursday morning. 1. The blog will be hosted on the Apache Blogs site[1]. 2. The blog will be set up using the instructions at [2] to enable public preview. 3. Proposed blog content will be posted in full-text or link form to the dev mailing list. 4. Blog content requires Lazy Approval votes that are open for at least 3 days. 5. Content may be cross-posted from other sites provided that the content is more than just a link to the other site. The full text of the original article is preferred. 6. Content may be cross-posted to other sites provided that there is a link back to the Accumulo blog site. [1] http://blogs.apache.org/ [2] http://www.apache.org/dev/project-blogs
Re: [VOTE] Accumulo Blog
+1 On Mon, Apr 14, 2014 at 10:35 AM, Corey Nolet cjno...@gmail.com wrote: +1 On Mon, Apr 14, 2014 at 11:18 AM, Joey Echeverria j...@clouderagovt.com wrote: +1 (non-binding) -- Joey Echeverria Chief Architect Cloudera Government Solutions On Mon, Apr 14, 2014 at 11:16 AM, Josh Elser josh.el...@gmail.com wrote: +1 On 4/13/14, 8:11 PM, dlmar...@comcast.net wrote: I have reviewed the feedback from the proposal thread and consolidated it into a set of guidelines for an Accumulo Blog. In accordance with the bylaws this vote will require Lazy Approval to pass and will remain open for 3 business days. I'll tally the votes on Thursday morning. 1. The blog will be hosted on the Apache Blogs site[1]. 2. The blog will be set up using the instructions at [2] to enable public preview. 3. Proposed blog content will be posted in full-text or link form to the dev mailing list. 4. Blog content requires Lazy Approval votes that are open for at least 3 days. 5. Content may be cross-posted from other sites provided that the content is more than just a link to the other site. The full text of the original article is preferred. 6. Content may be cross-posted to other sites provided that there is a link back to the Accumulo blog site. [1] http://blogs.apache.org/ [2] http://www.apache.org/dev/project-blogs
Re: [VOTE] Accumulo Blog
+0 -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Sun, Apr 13, 2014 at 8:11 PM, dlmar...@comcast.net wrote: I have reviewed the feedback from the proposal thread and consolidated it into a set of guidelines for an Accumulo Blog. In accordance with the bylaws this vote will require Lazy Approval to pass and will remain open for 3 business days. I'll tally the votes on Thursday morning. 1. The blog will be hosted on the Apache Blogs site[1]. 2. The blog will be set up using the instructions at [2] to enable public preview. 3. Proposed blog content will be posted in full-text or link form to the dev mailing list. 4. Blog content requires Lazy Approval votes that are open for at least 3 days. 5. Content may be cross-posted from other sites provided that the content is more than just a link to the other site. The full text of the original article is preferred. 6. Content may be cross-posted to other sites provided that there is a link back to the Accumulo blog site. [1] http://blogs.apache.org/ [2] http://www.apache.org/dev/project-blogs
Re: Is v1.4.2 downloadable?
All non-current releases are available in the archives. https://archive.apache.org/dist/accumulo/1.4.2/ On Mon, Apr 14, 2014 at 2:43 PM, David Medinets david.medin...@gmail.comwrote: http://accumulo.apache.org/downloads/ - I looked on this page and did not see v1.4.2. Nor do I see a v1.4.2 branch on this github site. Is it available somewhere else?
Re: Is v1.4.2 downloadable?
There's a 1.4.2 tag on github: https://github.com/apache/accumulo/tree/1.4.2 On Mon, Apr 14, 2014 at 2:43 PM, David Medinets david.medin...@gmail.com wrote: http://accumulo.apache.org/downloads/ - I looked on this page and did not see v1.4.2. Nor do I see a v1.4.2 branch on this github site. Is it available somewhere else?
Re: Is v1.4.2 downloadable?
there is also a 1.4.2 tag on the asf repo https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=tag;h=0cc5eeec51aa9efce75afed4fc4f44e1c4a33774 On Mon, Apr 14, 2014 at 11:46 AM, Joey Echeverria joey...@clouderagovt.comwrote: There's a 1.4.2 tag on github: https://github.com/apache/accumulo/tree/1.4.2 On Mon, Apr 14, 2014 at 2:43 PM, David Medinets david.medin...@gmail.com wrote: http://accumulo.apache.org/downloads/ - I looked on this page and did not see v1.4.2. Nor do I see a v1.4.2 branch on this github site. Is it available somewhere else? -- Sean
Re: Is v1.4.2 downloadable?
I didn't see there were both Branches and Tags on github. Thanks. And thanks for the archive link. On Mon, Apr 14, 2014 at 2:46 PM, Joey Echeverria joey...@clouderagovt.comwrote: There's a 1.4.2 tag on github: https://github.com/apache/accumulo/tree/1.4.2 On Mon, Apr 14, 2014 at 2:43 PM, David Medinets david.medin...@gmail.com wrote: http://accumulo.apache.org/downloads/ - I looked on this page and did not see v1.4.2. Nor do I see a v1.4.2 branch on this github site. Is it available somewhere else?
Re: [VOTE] Accumulo 1.6.0-RC1
This file has an incomplete license: core/src/test/resources/shelltest.txt but I don't think that's a blocker due to the trivial contents of the file. The src tarball matches the git branch. There are no javadocs in the bin tarball. There is no pre-built native map in the bin tarball (but I built one easily using the provided script). Is that expected? On Fri, Apr 11, 2014 at 3:41 PM, Christopher ctubb...@apache.org wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.6.0. Git Commit: 86a9a8a1d4f5215039ad2cfe86b0b7397455838a Branch: 1.6.0-RC1 Staging repo: https://repository.apache.org/content/repositories/orgapacheaccumulo-1007 Source: https://repository.apache.org/content/repositories/orgapacheaccumulo-1007/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz Binary: https://repository.apache.org/content/repositories/orgapacheaccumulo-1007/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 This vote will remain open for 96 hours (4 days, due to the weekend, and because I know some people want to finish some long tests), until Tue, April 15, 23:00 UTC 2014. (That's 7pm EDT.) [ ] +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-1007/ # note the trailing slash is needed -- Christopher L Tubbs II http://gravatar.com/ctubbsii
Re: [VOTE] Accumulo 1.6.0-RC1
On Mon, Apr 14, 2014 at 4:02 PM, Billie Rinaldi billie.rina...@gmail.com wrote: This file has an incomplete license: core/src/test/resources/shelltest.txt but I don't think that's a blocker due to the trivial contents of the file. The src tarball matches the git branch. There are no javadocs in the bin tarball. Right, I stripped them out as part of https://issues.apache.org/jira/browse/ACCUMULO-1487 This is expected. There is no pre-built native map in the bin tarball (but I built one easily using the provided script). Is that expected? This is also expected. It's easier to provide a platform-independent artifact that can be easily built, than guess at the target environment and produce something that will likely have to be recompiled anyway. On Fri, Apr 11, 2014 at 3:41 PM, Christopher ctubb...@apache.org wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.6.0. Git Commit: 86a9a8a1d4f5215039ad2cfe86b0b7397455838a Branch: 1.6.0-RC1 Staging repo: https://repository.apache.org/content/repositories/orgapacheaccumulo-1007 Source: https://repository.apache.org/content/repositories/orgapacheaccumulo-1007/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz Binary: https://repository.apache.org/content/repositories/orgapacheaccumulo-1007/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 This vote will remain open for 96 hours (4 days, due to the weekend, and because I know some people want to finish some long tests), until Tue, April 15, 23:00 UTC 2014. (That's 7pm EDT.) [ ] +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-1007/ # note the trailing slash is needed -- Christopher L Tubbs II http://gravatar.com/ctubbsii
Re: NOT operator in visibility string
I was recently talking to Aaron Cordova, and he asked me to chime into this thread, based on some of the work that I have done and graduate work that I have done in the access control space. Mixing positive and negative authorizations for visibility is certainly doable; however, there are some challenges related to doing so. When you give people the possibility of combining positive and negative access control policies, you also give them the potential to creating conflicts that could (1) make something invisible to everyone [perfect security?], or (2) make something visible to everyone.. And someone could do both of these, unintentionally. Ex1: A simple policy like *(A !A) *will make something non-accessible (and this trivial to see). At the same time, a complex policy like *((A|B)(C|D)(E|F)(G|!A))* could *potentially* resolve to a policy that would deny everyone access, because in the case of someone who doesn't have B or G (and someone who has C|D and E|F), *A* and *!A* would cancel themselves out. Ex2: In the same way, someone could build another policy that might resolve to something like* (A|!A) *which would resolve to no security at all. So if you were to build a system that mixed negative and positive operators, I think there would be a need to have a *policy resolver* to make sure that a well-intentioned developer was not accidentally disabling security or making something completely invisible and useless to everyone. You can see that there is a lot of academic research on conflict resolution when it comes to mixing positive and negative authorizations (see paper below): https://www.site.uottawa.ca/~luigi/papers/09_adi_bouzida_hattak.pdf The above paper doesn't make a case for NOT mixing positive and negative authorizations, but you can see that by not mixing them, you can avoid a number of pitfalls. With some work, any negative authorization statements can be re-written as positives. I've had to do this for a number of systems for RBAC (which only does positive authorizations). Anyway - just something to think about. I hope this helps! Kevin T. Smith
Review Request 20331: ACCUMULO-2666 Set a scalable default timeout for all functional tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20331/ --- Review request for accumulo. Bugs: ACCUMULO-2666 https://issues.apache.org/jira/browse/ACCUMULO-2666 Repository: accumulo Description --- Creates a default timeout for all functional ITs in a way that we can scale at test time via a system property, using a JUnit Rule instead of the timeout parameter to the Test annotation. per-method annotation can still override this (and still does in a few cases) Diffs - test/pom.xml 4ec6f6a test/src/test/java/org/apache/accumulo/test/functional/AbstractMacIT.java 352470c test/src/test/java/org/apache/accumulo/test/functional/AddSplitIT.java cc2285e test/src/test/java/org/apache/accumulo/test/functional/BackupMasterIT.java 7c1f8a2 test/src/test/java/org/apache/accumulo/test/functional/BadIteratorMincIT.java a25e775 test/src/test/java/org/apache/accumulo/test/functional/BalanceAfterCommsFailureIT.java a16ec2f test/src/test/java/org/apache/accumulo/test/functional/BatchScanSplitIT.java 22f0d98 test/src/test/java/org/apache/accumulo/test/functional/BatchWriterFlushIT.java 34fb402 test/src/test/java/org/apache/accumulo/test/functional/BigRootTabletIT.java 0e0671b test/src/test/java/org/apache/accumulo/test/functional/BinaryIT.java d5a4ffd test/src/test/java/org/apache/accumulo/test/functional/BinaryStressIT.java 7338095 test/src/test/java/org/apache/accumulo/test/functional/BloomFilterIT.java 9ba713d test/src/test/java/org/apache/accumulo/test/functional/BulkFileIT.java 10fb7f4 test/src/test/java/org/apache/accumulo/test/functional/BulkIT.java faa9391 test/src/test/java/org/apache/accumulo/test/functional/BulkSplitOptimizationIT.java f9abc0d test/src/test/java/org/apache/accumulo/test/functional/ChaoticBalancerIT.java 67a2d8c test/src/test/java/org/apache/accumulo/test/functional/ClassLoaderIT.java adc49d9 test/src/test/java/org/apache/accumulo/test/functional/CleanTmpIT.java 3ad9a3c test/src/test/java/org/apache/accumulo/test/functional/CleanUpIT.java 2c878e3 test/src/test/java/org/apache/accumulo/test/functional/CloneTestIT.java 29f838b test/src/test/java/org/apache/accumulo/test/functional/CombinerIT.java be1a709 test/src/test/java/org/apache/accumulo/test/functional/CompactionIT.java e7ccdd2 test/src/test/java/org/apache/accumulo/test/functional/ConcurrencyIT.java b2d16ad test/src/test/java/org/apache/accumulo/test/functional/ConstraintIT.java ef2212d test/src/test/java/org/apache/accumulo/test/functional/CreateAndUseIT.java 3dbf5ce test/src/test/java/org/apache/accumulo/test/functional/CreateManyScannersIT.java e627218 test/src/test/java/org/apache/accumulo/test/functional/DeleteEverythingIT.java e251157 test/src/test/java/org/apache/accumulo/test/functional/DeleteIT.java fe51039 test/src/test/java/org/apache/accumulo/test/functional/DeleteRowsIT.java 0731e44 test/src/test/java/org/apache/accumulo/test/functional/DeleteRowsSplitIT.java 0a0b0b9 test/src/test/java/org/apache/accumulo/test/functional/DeleteTableDuringSplitIT.java cd69be7 test/src/test/java/org/apache/accumulo/test/functional/DynamicThreadPoolsIT.java c89b8ce test/src/test/java/org/apache/accumulo/test/functional/FateStarvationIT.java 6ac2ef9 test/src/test/java/org/apache/accumulo/test/functional/HalfDeadTServerIT.java 0346f2f test/src/test/java/org/apache/accumulo/test/functional/LargeRowIT.java 31783c4 test/src/test/java/org/apache/accumulo/test/functional/LateLastContactIT.java fc2ed52 test/src/test/java/org/apache/accumulo/test/functional/LogicalTimeIT.java add7d8a test/src/test/java/org/apache/accumulo/test/functional/MapReduceIT.java ee5831b test/src/test/java/org/apache/accumulo/test/functional/MasterAssignmentIT.java 354a97d test/src/test/java/org/apache/accumulo/test/functional/MasterFailoverIT.java 8fd1499 test/src/test/java/org/apache/accumulo/test/functional/MaxOpenIT.java 72ad0f7 test/src/test/java/org/apache/accumulo/test/functional/MetadataMaxFiles.java b83a7de test/src/test/java/org/apache/accumulo/test/functional/MetadataSplitIT.java 3339698 test/src/test/java/org/apache/accumulo/test/functional/ReadWriteIT.java e845d99 test/src/test/java/org/apache/accumulo/test/functional/RenameIT.java 135b4e0 test/src/test/java/org/apache/accumulo/test/functional/RestartStressIT.java 06cdb8c test/src/test/java/org/apache/accumulo/test/functional/RowDeleteIT.java 886af49 test/src/test/java/org/apache/accumulo/test/functional/ScanIteratorIT.java c62592b test/src/test/java/org/apache/accumulo/test/functional/ScanRangeIT.java 818cf92 test/src/test/java/org/apache/accumulo/test/functional/ScanSessionTimeOutIT.java 693a67d
Re: Review Request 20331: ACCUMULO-2666 Set a scalable default timeout for all functional tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20331/#review40317 --- Ship it! test/src/test/java/org/apache/accumulo/test/functional/AbstractMacIT.java https://reviews.apache.org/r/20331/#comment73293 rename to defaultTimeoutMillis to be more explicit? - Vikram Srivastava On April 14, 2014, 11:02 p.m., Sean Busbey wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20331/ --- (Updated April 14, 2014, 11:02 p.m.) Review request for accumulo. Bugs: ACCUMULO-2666 https://issues.apache.org/jira/browse/ACCUMULO-2666 Repository: accumulo Description --- Creates a default timeout for all functional ITs in a way that we can scale at test time via a system property, using a JUnit Rule instead of the timeout parameter to the Test annotation. per-method annotation can still override this (and still does in a few cases) Diffs - test/pom.xml 4ec6f6a test/src/test/java/org/apache/accumulo/test/functional/AbstractMacIT.java 352470c test/src/test/java/org/apache/accumulo/test/functional/AddSplitIT.java cc2285e test/src/test/java/org/apache/accumulo/test/functional/BackupMasterIT.java 7c1f8a2 test/src/test/java/org/apache/accumulo/test/functional/BadIteratorMincIT.java a25e775 test/src/test/java/org/apache/accumulo/test/functional/BalanceAfterCommsFailureIT.java a16ec2f test/src/test/java/org/apache/accumulo/test/functional/BatchScanSplitIT.java 22f0d98 test/src/test/java/org/apache/accumulo/test/functional/BatchWriterFlushIT.java 34fb402 test/src/test/java/org/apache/accumulo/test/functional/BigRootTabletIT.java 0e0671b test/src/test/java/org/apache/accumulo/test/functional/BinaryIT.java d5a4ffd test/src/test/java/org/apache/accumulo/test/functional/BinaryStressIT.java 7338095 test/src/test/java/org/apache/accumulo/test/functional/BloomFilterIT.java 9ba713d test/src/test/java/org/apache/accumulo/test/functional/BulkFileIT.java 10fb7f4 test/src/test/java/org/apache/accumulo/test/functional/BulkIT.java faa9391 test/src/test/java/org/apache/accumulo/test/functional/BulkSplitOptimizationIT.java f9abc0d test/src/test/java/org/apache/accumulo/test/functional/ChaoticBalancerIT.java 67a2d8c test/src/test/java/org/apache/accumulo/test/functional/ClassLoaderIT.java adc49d9 test/src/test/java/org/apache/accumulo/test/functional/CleanTmpIT.java 3ad9a3c test/src/test/java/org/apache/accumulo/test/functional/CleanUpIT.java 2c878e3 test/src/test/java/org/apache/accumulo/test/functional/CloneTestIT.java 29f838b test/src/test/java/org/apache/accumulo/test/functional/CombinerIT.java be1a709 test/src/test/java/org/apache/accumulo/test/functional/CompactionIT.java e7ccdd2 test/src/test/java/org/apache/accumulo/test/functional/ConcurrencyIT.java b2d16ad test/src/test/java/org/apache/accumulo/test/functional/ConstraintIT.java ef2212d test/src/test/java/org/apache/accumulo/test/functional/CreateAndUseIT.java 3dbf5ce test/src/test/java/org/apache/accumulo/test/functional/CreateManyScannersIT.java e627218 test/src/test/java/org/apache/accumulo/test/functional/DeleteEverythingIT.java e251157 test/src/test/java/org/apache/accumulo/test/functional/DeleteIT.java fe51039 test/src/test/java/org/apache/accumulo/test/functional/DeleteRowsIT.java 0731e44 test/src/test/java/org/apache/accumulo/test/functional/DeleteRowsSplitIT.java 0a0b0b9 test/src/test/java/org/apache/accumulo/test/functional/DeleteTableDuringSplitIT.java cd69be7 test/src/test/java/org/apache/accumulo/test/functional/DynamicThreadPoolsIT.java c89b8ce test/src/test/java/org/apache/accumulo/test/functional/FateStarvationIT.java 6ac2ef9 test/src/test/java/org/apache/accumulo/test/functional/HalfDeadTServerIT.java 0346f2f test/src/test/java/org/apache/accumulo/test/functional/LargeRowIT.java 31783c4 test/src/test/java/org/apache/accumulo/test/functional/LateLastContactIT.java fc2ed52 test/src/test/java/org/apache/accumulo/test/functional/LogicalTimeIT.java add7d8a test/src/test/java/org/apache/accumulo/test/functional/MapReduceIT.java ee5831b test/src/test/java/org/apache/accumulo/test/functional/MasterAssignmentIT.java 354a97d test/src/test/java/org/apache/accumulo/test/functional/MasterFailoverIT.java 8fd1499 test/src/test/java/org/apache/accumulo/test/functional/MaxOpenIT.java 72ad0f7 test/src/test/java/org/apache/accumulo/test/functional/MetadataMaxFiles.java b83a7de
Re: Review Request 20331: ACCUMULO-2666 Set a scalable default timeout for all functional tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20331/#review40318 --- Ship it! - Vikram Srivastava On April 14, 2014, 11:02 p.m., Sean Busbey wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20331/ --- (Updated April 14, 2014, 11:02 p.m.) Review request for accumulo. Bugs: ACCUMULO-2666 https://issues.apache.org/jira/browse/ACCUMULO-2666 Repository: accumulo Description --- Creates a default timeout for all functional ITs in a way that we can scale at test time via a system property, using a JUnit Rule instead of the timeout parameter to the Test annotation. per-method annotation can still override this (and still does in a few cases) Diffs - test/pom.xml 4ec6f6a test/src/test/java/org/apache/accumulo/test/functional/AbstractMacIT.java 352470c test/src/test/java/org/apache/accumulo/test/functional/AddSplitIT.java cc2285e test/src/test/java/org/apache/accumulo/test/functional/BackupMasterIT.java 7c1f8a2 test/src/test/java/org/apache/accumulo/test/functional/BadIteratorMincIT.java a25e775 test/src/test/java/org/apache/accumulo/test/functional/BalanceAfterCommsFailureIT.java a16ec2f test/src/test/java/org/apache/accumulo/test/functional/BatchScanSplitIT.java 22f0d98 test/src/test/java/org/apache/accumulo/test/functional/BatchWriterFlushIT.java 34fb402 test/src/test/java/org/apache/accumulo/test/functional/BigRootTabletIT.java 0e0671b test/src/test/java/org/apache/accumulo/test/functional/BinaryIT.java d5a4ffd test/src/test/java/org/apache/accumulo/test/functional/BinaryStressIT.java 7338095 test/src/test/java/org/apache/accumulo/test/functional/BloomFilterIT.java 9ba713d test/src/test/java/org/apache/accumulo/test/functional/BulkFileIT.java 10fb7f4 test/src/test/java/org/apache/accumulo/test/functional/BulkIT.java faa9391 test/src/test/java/org/apache/accumulo/test/functional/BulkSplitOptimizationIT.java f9abc0d test/src/test/java/org/apache/accumulo/test/functional/ChaoticBalancerIT.java 67a2d8c test/src/test/java/org/apache/accumulo/test/functional/ClassLoaderIT.java adc49d9 test/src/test/java/org/apache/accumulo/test/functional/CleanTmpIT.java 3ad9a3c test/src/test/java/org/apache/accumulo/test/functional/CleanUpIT.java 2c878e3 test/src/test/java/org/apache/accumulo/test/functional/CloneTestIT.java 29f838b test/src/test/java/org/apache/accumulo/test/functional/CombinerIT.java be1a709 test/src/test/java/org/apache/accumulo/test/functional/CompactionIT.java e7ccdd2 test/src/test/java/org/apache/accumulo/test/functional/ConcurrencyIT.java b2d16ad test/src/test/java/org/apache/accumulo/test/functional/ConstraintIT.java ef2212d test/src/test/java/org/apache/accumulo/test/functional/CreateAndUseIT.java 3dbf5ce test/src/test/java/org/apache/accumulo/test/functional/CreateManyScannersIT.java e627218 test/src/test/java/org/apache/accumulo/test/functional/DeleteEverythingIT.java e251157 test/src/test/java/org/apache/accumulo/test/functional/DeleteIT.java fe51039 test/src/test/java/org/apache/accumulo/test/functional/DeleteRowsIT.java 0731e44 test/src/test/java/org/apache/accumulo/test/functional/DeleteRowsSplitIT.java 0a0b0b9 test/src/test/java/org/apache/accumulo/test/functional/DeleteTableDuringSplitIT.java cd69be7 test/src/test/java/org/apache/accumulo/test/functional/DynamicThreadPoolsIT.java c89b8ce test/src/test/java/org/apache/accumulo/test/functional/FateStarvationIT.java 6ac2ef9 test/src/test/java/org/apache/accumulo/test/functional/HalfDeadTServerIT.java 0346f2f test/src/test/java/org/apache/accumulo/test/functional/LargeRowIT.java 31783c4 test/src/test/java/org/apache/accumulo/test/functional/LateLastContactIT.java fc2ed52 test/src/test/java/org/apache/accumulo/test/functional/LogicalTimeIT.java add7d8a test/src/test/java/org/apache/accumulo/test/functional/MapReduceIT.java ee5831b test/src/test/java/org/apache/accumulo/test/functional/MasterAssignmentIT.java 354a97d test/src/test/java/org/apache/accumulo/test/functional/MasterFailoverIT.java 8fd1499 test/src/test/java/org/apache/accumulo/test/functional/MaxOpenIT.java 72ad0f7 test/src/test/java/org/apache/accumulo/test/functional/MetadataMaxFiles.java b83a7de test/src/test/java/org/apache/accumulo/test/functional/MetadataSplitIT.java 3339698 test/src/test/java/org/apache/accumulo/test/functional/ReadWriteIT.java e845d99
Re: Review Request 20331: ACCUMULO-2666 Set a scalable default timeout for all functional tests.
On April 14, 2014, 11:09 p.m., Vikram Srivastava wrote: test/src/test/java/org/apache/accumulo/test/functional/AbstractMacIT.java, line 147 https://reviews.apache.org/r/20331/diff/2/?file=557645#file557645line147 rename to defaultTimeoutMillis to be more explicit? Actually, now that you mention it. Should this just be defaultTimeoutSeconds? Almost all of the timeouts are actually measured in minutes right now. So while the few timeouts in seconds justify not using defaultTimeoutMinutes, they make it seem very unlikely that we'll want to tune timeouts in the milliseconds range. - Sean --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20331/#review40317 --- On April 14, 2014, 11:02 p.m., Sean Busbey wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20331/ --- (Updated April 14, 2014, 11:02 p.m.) Review request for accumulo. Bugs: ACCUMULO-2666 https://issues.apache.org/jira/browse/ACCUMULO-2666 Repository: accumulo Description --- Creates a default timeout for all functional ITs in a way that we can scale at test time via a system property, using a JUnit Rule instead of the timeout parameter to the Test annotation. per-method annotation can still override this (and still does in a few cases) Diffs - test/pom.xml 4ec6f6a test/src/test/java/org/apache/accumulo/test/functional/AbstractMacIT.java 352470c test/src/test/java/org/apache/accumulo/test/functional/AddSplitIT.java cc2285e test/src/test/java/org/apache/accumulo/test/functional/BackupMasterIT.java 7c1f8a2 test/src/test/java/org/apache/accumulo/test/functional/BadIteratorMincIT.java a25e775 test/src/test/java/org/apache/accumulo/test/functional/BalanceAfterCommsFailureIT.java a16ec2f test/src/test/java/org/apache/accumulo/test/functional/BatchScanSplitIT.java 22f0d98 test/src/test/java/org/apache/accumulo/test/functional/BatchWriterFlushIT.java 34fb402 test/src/test/java/org/apache/accumulo/test/functional/BigRootTabletIT.java 0e0671b test/src/test/java/org/apache/accumulo/test/functional/BinaryIT.java d5a4ffd test/src/test/java/org/apache/accumulo/test/functional/BinaryStressIT.java 7338095 test/src/test/java/org/apache/accumulo/test/functional/BloomFilterIT.java 9ba713d test/src/test/java/org/apache/accumulo/test/functional/BulkFileIT.java 10fb7f4 test/src/test/java/org/apache/accumulo/test/functional/BulkIT.java faa9391 test/src/test/java/org/apache/accumulo/test/functional/BulkSplitOptimizationIT.java f9abc0d test/src/test/java/org/apache/accumulo/test/functional/ChaoticBalancerIT.java 67a2d8c test/src/test/java/org/apache/accumulo/test/functional/ClassLoaderIT.java adc49d9 test/src/test/java/org/apache/accumulo/test/functional/CleanTmpIT.java 3ad9a3c test/src/test/java/org/apache/accumulo/test/functional/CleanUpIT.java 2c878e3 test/src/test/java/org/apache/accumulo/test/functional/CloneTestIT.java 29f838b test/src/test/java/org/apache/accumulo/test/functional/CombinerIT.java be1a709 test/src/test/java/org/apache/accumulo/test/functional/CompactionIT.java e7ccdd2 test/src/test/java/org/apache/accumulo/test/functional/ConcurrencyIT.java b2d16ad test/src/test/java/org/apache/accumulo/test/functional/ConstraintIT.java ef2212d test/src/test/java/org/apache/accumulo/test/functional/CreateAndUseIT.java 3dbf5ce test/src/test/java/org/apache/accumulo/test/functional/CreateManyScannersIT.java e627218 test/src/test/java/org/apache/accumulo/test/functional/DeleteEverythingIT.java e251157 test/src/test/java/org/apache/accumulo/test/functional/DeleteIT.java fe51039 test/src/test/java/org/apache/accumulo/test/functional/DeleteRowsIT.java 0731e44 test/src/test/java/org/apache/accumulo/test/functional/DeleteRowsSplitIT.java 0a0b0b9 test/src/test/java/org/apache/accumulo/test/functional/DeleteTableDuringSplitIT.java cd69be7 test/src/test/java/org/apache/accumulo/test/functional/DynamicThreadPoolsIT.java c89b8ce test/src/test/java/org/apache/accumulo/test/functional/FateStarvationIT.java 6ac2ef9 test/src/test/java/org/apache/accumulo/test/functional/HalfDeadTServerIT.java 0346f2f test/src/test/java/org/apache/accumulo/test/functional/LargeRowIT.java 31783c4 test/src/test/java/org/apache/accumulo/test/functional/LateLastContactIT.java fc2ed52 test/src/test/java/org/apache/accumulo/test/functional/LogicalTimeIT.java add7d8a test/src/test/java/org/apache/accumulo/test/functional/MapReduceIT.java ee5831b
Re: [VOTE] Accumulo 1.6.0-RC1
This should be included in the release notes as it is a divergence from 1.5. Should I open a ticket for that, Christopher? On 4/14/14, 4:47 PM, Christopher wrote: There is no pre-built native map in the bin tarball (but I built one easily using the provided script). Is that expected? This is also expected. It's easier to provide a platform-independent artifact that can be easily built, than guess at the target environment and produce something that will likely have to be recompiled anyway.
Re: [VOTE] Accumulo 1.6.0-RC1
release notes for 1.6.0 are still being created[1]. I don't believe the intention is to bundle them into the release artifact, similar to 1.5.1. [1]: https://issues.apache.org/jira/browse/ACCUMULO-2396 On Mon, Apr 14, 2014 at 8:40 PM, Josh Elser josh.el...@gmail.com wrote: This should be included in the release notes as it is a divergence from 1.5. Should I open a ticket for that, Christopher? On 4/14/14, 4:47 PM, Christopher wrote: There is no pre-built native map in the bin tarball (but I built one easily using the provided script). Is that expected? This is also expected. It's easier to provide a platform-independent artifact that can be easily built, than guess at the target environment and produce something that will likely have to be recompiled anyway. -- Sean
Re: [VOTE] Accumulo 1.6.0-RC1
Yes, I was aware of the intent, but I had thought we closed out that ticket. I'll comment there. On 4/14/14, 11:43 PM, Sean Busbey wrote: release notes for 1.6.0 are still being created[1]. I don't believe the intention is to bundle them into the release artifact, similar to 1.5.1. [1]: https://issues.apache.org/jira/browse/ACCUMULO-2396 On Mon, Apr 14, 2014 at 8:40 PM, Josh Elser josh.el...@gmail.com wrote: This should be included in the release notes as it is a divergence from 1.5. Should I open a ticket for that, Christopher? On 4/14/14, 4:47 PM, Christopher wrote: There is no pre-built native map in the bin tarball (but I built one easily using the provided script). Is that expected? This is also expected. It's easier to provide a platform-independent artifact that can be easily built, than guess at the target environment and produce something that will likely have to be recompiled anyway.
Re: [VOTE] Accumulo 1.6.0-RC1
-1 due to the large performance regression (~40% degradation) identified by Jonathan Park in ACCUMULO-2668 Additionally, it would be nice to get ACCUMULO-2665 to ensure that we can unit test against Apache Hadoop 2.4.0 for 1.6.0, but I am not -1 on that issue alone (just -0 if it comes to that). Aside from those two, the rest of the release looks pretty good to me: * Used 86a9a8a1 to run unit and integration tests against Apache Hadoop 2.2.0, 2.3.0, and 2.4.0 (with ACCUMULO-2665 caveat for 2.4.0) * Verified sigs and hashes for tarballs (didn't write a script to verify all sigs from the staging repo -- I trust nexus here) * Ran short CI+verification on Apache Hadoop 2.3.0 * Ran short CI on Apache Hadoop 2.4.0 (ran into an issue with launching the verification job -- maybe it's just me doing something dumb?) * Verified basic compatibility with Apache Pig 0.13.0-SNAPSHOT (caveat PIG-3885). Read/Write data, join two tables. * Downloaded source tarball, built jars and nativemaps, ran unit and integration tests, and tested basic read/write test on Apache Hadoop 2.3.0 * Downloaded binary tarball, built nativemaps, tested basic read/write on Apache Hadoop 2.3.0 One final (repeated) comment, the binary tarball lack of a prebuilt native map. I believe this merits mention in the release notes before those are finalized. I will update this. On 4/11/14, 6:41 PM, Christopher wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.6.0. Git Commit: 86a9a8a1d4f5215039ad2cfe86b0b7397455838a Branch: 1.6.0-RC1 Staging repo: https://repository.apache.org/content/repositories/orgapacheaccumulo-1007 Source: https://repository.apache.org/content/repositories/orgapacheaccumulo-1007/org/apache/accumulo/accumulo/1.6.0/accumulo-1.6.0-src.tar.gz Binary: https://repository.apache.org/content/repositories/orgapacheaccumulo-1007/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 This vote will remain open for 96 hours (4 days, due to the weekend, and because I know some people want to finish some long tests), until Tue, April 15, 23:00 UTC 2014. (That's 7pm EDT.) [ ] +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-1007/ # note the trailing slash is needed -- Christopher L Tubbs II http://gravatar.com/ctubbsii
