Re: Review Request 20024: ACCUMULO-2627 use try-with-resources

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20024/ --- (Updated April 5, 2014, 12:41 a.m.) Review request for accumulo. Changes

Re: Review Request 20024: ACCUMULO-2627 use try-with-resources

> On April 4, 2014, 2:21 p.m., Bill Havanki wrote: > > core/src/main/java/org/apache/accumulo/core/client/mapreduce/lib/util/InputConfigurator.java, > > line 237 > > > > > > ByteArrayInputStream.close() has no effect.

Re: [DISCUSS] Remove hadoop1 support

Yes. It would mean updating our README and adding something to the Release Notes. In addition to the "we don't recommend it" text, a warning that we plan to remove it in the next version would also be good. -Sean On Fri, Apr 4, 2014 at 7:25 PM, Josh Elser wrote: > Everyone else correct me if

Re: [DISCUSS] Remove hadoop1 support

Everyone else correct me if I'm mistaken, but I assume "deprecate Hadoop 1 for 1.6.0" would primarily be an advertising/documentation change. Let people know that it works, but it's not recommended that you use it". On 4/4/14, 8:23 PM, Christopher wrote: I'm not sure what it means to "deprecat

Re: [DISCUSS] Remove hadoop1 support

I'm not sure what it means to "deprecate" support in 1.6.0. Changing a minimum dependency isn't something you can really "deprecate" in the traditional sense of code deprecation. Perhaps this would mean just annotating in the 1.6.x release notes that this will be the last version supporting Hadoop

Re: [DISCUSS] Bugs-only strictness for bugfix releases

None of our previous 1.x releases met semver's requirements for a minor version, so I don't think we need to worry about adopting that approach as a part of the 1.6.0 release cycle. There are a ton of reasons I want a 2.0.0. Given the significance of that change I think we should have a discussio

Re: [DISCUSS] Bugs-only strictness for bugfix releases

It's probably true that 1.6.0 currently would not meet semver's requirements for minor release compatibility, but something like this I think should probably change at the beginning of a dev cycle, not at the end. It seems to me that 1.7.0 would be the time to apply this, considering it 1) has a di

Re: Review Request 19804: ACCUMULO-2519 Aborts upgrade if there are Fate transactions from an old version.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19804/#review39607 --- Ship it! Ship It! - Josh Elser On April 4, 2014, 10:28 p.m., Sea

Re: Review Request 19804: ACCUMULO-2519 Aborts upgrade if there are Fate transactions from an old version.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19804/ --- (Updated April 4, 2014, 10:28 p.m.) Review request for accumulo and kturner.

Re: [RESULT][VOTE] Accumulo 1.4.5 RC-2

Tag has been gpg signed. 1.4.5-SNAPSHOT branch has been deleted. 1.4.6-SNAPSHOT branch has been created. Maven repository has been promoted. JIRA version has been marked as released. DOAP has been updated. Artifacts have been replaced in SVN. Todo: Update website after artifacts propagate to mirro

Re: [DISCUSS] Remove hadoop1 support

+1 to deprecating hadoop1 support in 1.6.0 +1 to dropping hadoop1 support in 1.7.0 (or similar release) -- Joey Echeverria Chief Architect Cloudera Government Solutions On Fri, Apr 4, 2014 at 11:28 AM, Josh Elser wrote: > +1 ditto on what's been said > > Not sure on how "aggressive" it would be

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

That leaves me conflicted. I have a substantial dislike for doing things a way solely because that's how they have been. I can see the value in keeping things similar for those who interact, but how much is that? I'm not sure how much confusion there will be should these actions happen if we're pr

Re: [DISCUSS] Reviewing design documents

On 4/4/14, 2:09 PM, Keith Turner wrote: On Fri, Apr 4, 2014 at 1:49 PM, Josh Elser wrote: >Granted, the syntax is probably expressive enough to read, but viewing it >in plaintext isn't the same as having it "rendered". > >The lack of varying font size is probably the most noticeable problem. >

Re: [DISCUSS] Remove hadoop1 support

+1 ditto on what's been said Not sure on how "aggressive" it would be to call hadoop1 deprecated for 1.6.0, but I wouldn't mind seeing that happen. Can certainly poll the user list for input. We've already "encouraged" hadoop2 by switching the build profiles for 1.6, perhaps it's not unreasona

Re: [DISCUSS] Remove hadoop1 support

On Fri, Apr 4, 2014 at 1:20 PM, Ravi Mutyala wrote: > +1 for dropping support for hadoop1 in future versions. +1 to call it > deprecated for Hadoop 1. It might be to good option to get info from user > list if anyone is going to use 1.6 on Hadoop1. > > Lordy I hope no one is. Really, once the WAL

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

On Fri, Apr 4, 2014 at 1:18 PM, John Vines wrote: > I can accept those reasons for new persons in charge. What about vetoed > code and adding a new codebase? I can see the giving up control as a reason > to escalate things to Consensus from Majority, but I'm not seeing the > reason for these 2. >

Re: [DISCUSS] Remove hadoop1 support

I would be comfortable calling Hadoop 1 support in 1.6.0 deprecated. -Sean On Fri, Apr 4, 2014 at 1:07 PM, Mike Drob wrote: > https://issues.apache.org/jira/browse/HBASE-10690 > > Deprecated in 0.98, dropped in 1.0 > > > On Fri, Apr 4, 2014 at 11:02 AM, Sean Busbey wrote: > > > Mike, as of whi

Re: [DISCUSS] Remove hadoop1 support

+1 for dropping support for hadoop1 in future versions. +1 to call it deprecated for Hadoop 1. It might be to good option to get info from user list if anyone is going to use 1.6 on Hadoop1. Thanks On Fri, Apr 4, 2014 at 1:07 PM, Mike Drob wrote: > https://issues.apache.org/jira/browse/HBASE-1

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

I can accept those reasons for new persons in charge. What about vetoed code and adding a new codebase? I can see the giving up control as a reason to escalate things to Consensus from Majority, but I'm not seeing the reason for these 2. On Fri, Apr 4, 2014 at 1:40 PM, Sean Busbey wrote: > > >

Re: [DISCUSS] Define CTR in Bylaws

On Fri, Apr 4, 2014 at 1:10 PM, John Vines wrote: > Based on the actions table, consensus > oh yeah, its very clear there. thanks > > > On Fri, Apr 4, 2014 at 1:06 PM, Keith Turner wrote: > > > On Fri, Apr 4, 2014 at 12:12 PM, Billie Rinaldi < > billie.rina...@gmail.com > > >wrote: > > > > >

Re: [DISCUSS] Reviewing design documents

On Fri, Apr 4, 2014 at 1:49 PM, Josh Elser wrote: > Granted, the syntax is probably expressive enough to read, but viewing it > in plaintext isn't the same as having it "rendered". > > The lack of varying font size is probably the most noticeable problem. > Trying to read a table in raw markdown

Re: [DISCUSS] Remove hadoop1 support

https://issues.apache.org/jira/browse/HBASE-10690 Deprecated in 0.98, dropped in 1.0 On Fri, Apr 4, 2014 at 11:02 AM, Sean Busbey wrote: > Mike, as of which version is HBase dropping? > > I wouldn't want to do this in 1.6.x. Presumably that would mean if we drop > it in the next version, we'd

Re: [DISCUSS] Remove hadoop1 support

Yes, I had assumed that all versions that support hadoop1 will continue. Only for major releases (1.x, or x if we pick up semantic versioning or something else) On Fri, Apr 4, 2014 at 2:02 PM, Sean Busbey wrote: > Mike, as of which version is HBase dropping? > > I wouldn't want to do this in 1.

Re: [DISCUSS] Remove hadoop1 support

Mike, as of which version is HBase dropping? I wouldn't want to do this in 1.6.x. Presumably that would mean if we drop it in the next version, we'd still be supporting Hadoop 1 until both 1.5 and 1.6 have been EOLd? -Sean On Fri, Apr 4, 2014 at 12:56 PM, Mike Drob wrote: > HBase has started

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

-1. I am in favor of the bylaws as a living document, and consensus makes it much more difficult to improve upon things if there is a large, but not universal, support. On Fri, Apr 4, 2014 at 10:40 AM, Sean Busbey wrote: > On Fri, Apr 4, 2014 at 12:19 PM, John Vines wrote: > > > So, I pseudo

Re: [DISCUSS] Remove hadoop1 support

HBase has started to drop hadoop 1 support already. On Fri, Apr 4, 2014 at 10:54 AM, John Vines wrote: > This is something that crossed my mind recently. Hadoop 2 is solidly moving > forward and, as someone who does not actively follow the hadoop community, > hadoop 1 is slowing down. Adoption

Re: [VOTE] Accumulo Bylaws - Action changes

-1, I would need replacement text to establish how we deal with disagreeing with a commit. On Fri, Apr 4, 2014 at 9:10 AM, Sean Busbey wrote: > On Fri, Apr 4, 2014 at 10:56 AM, John Vines wrote: > > > The current line is unacceptable. It can also be implied that every > single > > code change

[DISCUSS] Remove hadoop1 support

This is something that crossed my mind recently. Hadoop 2 is solidly moving forward and, as someone who does not actively follow the hadoop community, hadoop 1 is slowing down. Adoption for hadoop2 is on the rise and with that I'm starting to wonder whether it's worth the code complexity to support

Re: [DISCUSS] Reviewing design documents

On Fri, Apr 4, 2014 at 12:49 PM, Keith Turner wrote: > On Fri, Apr 4, 2014 at 1:40 PM, Alex Moundalexis >wrote: > > > On Fri, Apr 4, 2014 at 12:45 PM, Josh Elser > wrote: > > > > > > The localized commenting on reviewboard is nice, but making updates to > > the > > > document is definitely not

Re: [DISCUSS] Reviewing design documents

Granted, the syntax is probably expressive enough to read, but viewing it in plaintext isn't the same as having it "rendered". The lack of varying font size is probably the most noticeable problem. Trying to read a table in raw markdown is also a good example. Code snippets also are difficult

Re: [DISCUSS] Reviewing design documents

On Fri, Apr 4, 2014 at 1:40 PM, Alex Moundalexis wrote: > On Fri, Apr 4, 2014 at 12:45 PM, Josh Elser wrote: > > > > The localized commenting on reviewboard is nice, but making updates to > the > > document is definitely not fun. > > > > Why not use GitHub? it provides most of what you're using R

Re: [DISCUSS] Reviewing design documents

On Fri, Apr 4, 2014 at 12:45 PM, Josh Elser wrote: > > The localized commenting on reviewboard is nice, but making updates to the > document is definitely not fun. > Why not use GitHub? it provides most of what you're using RB for now, but: - Markdown is easily edited/previewed on GitHub - pull

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

On Fri, Apr 4, 2014 at 12:19 PM, John Vines wrote: > So, I pseudo got an explanation for the second point in the CtR discussion, > so I'm going to withdraw that comment. However, I would still appreciate an > explanation for initial paragraph. > > > On Fri, Apr 4, 2014 at 12:32 PM, John Vines wr

Re: [DISCUSS] Reviewing design documents

Why not have the design doc in markdown only? I assume its not expressive enough? For the ACCUMULO-1000 design doc I used asciidoc to try that out.The asciidoc source was readable like markdown and maybe more expressive than markdown On Fri, Apr 4, 2014 at 12:45 PM, Josh Elser wrote: > On

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

So, I pseudo got an explanation for the second point in the CtR discussion, so I'm going to withdraw that comment. However, I would still appreciate an explanation for initial paragraph. On Fri, Apr 4, 2014 at 12:32 PM, John Vines wrote: > The majority of the reasoning I read in the bylaws thre

Re: [DISCUSS] Define CTR in Bylaws

On Fri, Apr 4, 2014 at 12:06 PM, Keith Turner wrote: > On Fri, Apr 4, 2014 at 12:12 PM, Billie Rinaldi >wrote: > > > This is a proposal to adequately describe our Commit-Then-Review process > in > > the bylaws. I have made an initial suggestion below. If we can agree on > > how to make this cl

Re: [DISCUSS] Define CTR in Bylaws

Based on the actions table, consensus On Fri, Apr 4, 2014 at 1:06 PM, Keith Turner wrote: > On Fri, Apr 4, 2014 at 12:12 PM, Billie Rinaldi >wrote: > > > This is a proposal to adequately describe our Commit-Then-Review process > in > > the bylaws. I have made an initial suggestion below. If

Re: [DISCUSS] Define CTR in Bylaws

On Fri, Apr 4, 2014 at 12:12 PM, Billie Rinaldi wrote: > This is a proposal to adequately describe our Commit-Then-Review process in > the bylaws. I have made an initial suggestion below. If we can agree on > how to make this clarification, presumably this change would be made > instead of remov

Re: [DISCUSS] Define CTR in Bylaws

+1 for the initial changes Billie proposed. On Fri, Apr 4, 2014 at 12:53 PM, Sean Busbey wrote: > Yes, precisely. > > > On Fri, Apr 4, 2014 at 11:47 AM, John Vines wrote: > > > That makes sense, Sean. So are you saying that you think it's best to > > include no language whatsoever to enable re

Re: [DISCUSS] Define CTR in Bylaws

Yes, precisely. On Fri, Apr 4, 2014 at 11:47 AM, John Vines wrote: > That makes sense, Sean. So are you saying that you think it's best to > include no language whatsoever to enable restricting CtR vetoes during a > release? > > > On Fri, Apr 4, 2014 at 12:29 PM, Sean Busbey wrote: > >> I've s

Re: [DISCUSS] Define CTR in Bylaws

That makes sense, Sean. So are you saying that you think it's best to include no language whatsoever to enable restricting CtR vetoes during a release? On Fri, Apr 4, 2014 at 12:29 PM, Sean Busbey wrote: > I've spent some time dealing with hostiles in internet communities. Based > on my experie

Re: [DISCUSS] Reviewing design documents

On 3/28/14, 9:39 AM, Keith Turner wrote: On Fri, Mar 28, 2014 at 12:23 AM, Sean Busbeywrote: >Aside from the occasional stability problem, I really like the idea of >using ReviewBoard. It has the best option for in-context commenting amongst >our options at Apache AFAICT. > Another plus is tha

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

+1 - Original Message - From: "John Vines" To: "Accumulo Dev List" Sent: Friday, April 4, 2014 11:21:11 AM Subject: [VOTE] Accumulo Bylaws - Bylaw Change Changes This is a proposal to change the Bylaw Change action in the bylaws from Majority Approval to Consensus Approval. This

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

You're quoting me, but in the interest of community harmony I yield to another who may like to clarify. On Fri, Apr 4, 2014 at 12:32 PM, John Vines wrote: > The majority of the reasoning I read in the bylaws thread justifying why > bylaw changes should be majority and not consensus seemed to sp

Re: [DISCUSS] Define CTR in Bylaws

+1 when the description is crafted to fit the prevailing CtR practice. On Fri, Apr 4, 2014 at 12:35 PM, wrote: > +1 > I don't think that we need to cover all situations in the bylaws in the > early versions. We can amend as situations arise. > > > - Original Message - > > From: "Sean Bu

Re: [DISCUSS] Reviewing design documents

+1 for Gerrit. I have experience with it so let me know if you need my help. On Fri, Mar 28, 2014 at 9:39 AM, Keith Turner wrote: > On Fri, Mar 28, 2014 at 12:23 AM, Sean Busbey >wrote: > > > Aside from the occasional stability problem, I really like the idea of > > using ReviewBoard. It has t

Re: [DISCUSS] Define CTR in Bylaws

+1 I don't think that we need to cover all situations in the bylaws in the early versions. We can amend as situations arise. - Original Message - From: "Sean Busbey" To: "dev@accumulo apache. org" , vi...@apache.org Sent: Friday, April 4, 2014 12:29:48 PM Subject: Re: [DISCUSS] De

Re: Release testing for 1.6.0

It's ultimately up to the Release Manager if something should go into 1.6.0, but I don't see why we wouldn't include bug fixes that don't invalidate tests. IMHO, we have way too many development branches as is so in the case you're describing I'd rather have things wait in 1.5 instead of adding an

Re: [DISCUSS] Define CTR in Bylaws

include a time for review in the release process. Anyone can raise an objection at that time. If there is no objection, release plan moves forward. If objection, discuss, and vote if necessary. - Original Message - From: "John Vines" To: "Accumulo Dev List" Sent: Friday, April 4,

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

The majority of the reasoning I read in the bylaws thread justifying why bylaw changes should be majority and not consensus seemed to spiral around "We don't want someone to be able to torpedo the vote". Can someone who held this opinion clarify why this is unacceptable for a bylaw change but accep

Re: Release testing for 1.6.0

Bug fixes against 1.4.6 and 1.5.2 that aren't deemed as necessary for 1.6.0 will have no home in the 1.6 line if we don't have branches for 1.6.0 and 1.6.1. These commits would sit in limbo in the 1.5 branch until 1.6.0 is released and we make 1.6.1-SNAPSHOT as part of the release steps. That'

Re: [DISCUSS] Define CTR in Bylaws

I've spent some time dealing with hostiles in internet communities. Based on my experience, I would strongly recommend against gearing our bylaws towards guarding against actors we disagree with. 1) It presumes a conflict oriented community 2) It presumes we will have community members acting mal

Re: Release testing for 1.6.0

What kind of development are you worried about stalling? Ideally, bug fixes shouldn't involve such a severe change that we have to redo the long running tests. I would think that if such a fix did happen it would be for a problem severe enough to warrant delaying the release. On Fri, Apr 4, 2014

Re: [DISCUSS] Define CTR in Bylaws

In the bylaw discussion, we had discussed the potential for someone to reject a commit as a method to reject a release. Is this something that we want to guard against with every release (if possible, we may need to provide this ability in the bylaws) or should there be language in our definitions

Re: [DISCUSS] Define CTR in Bylaws

As previously stated, I like this proposed change and would vote in favor of it. On Fri, Apr 4, 2014 at 11:12 AM, Billie Rinaldi wrote: > This is a proposal to adequately describe our Commit-Then-Review process in > the bylaws. I have made an initial suggestion below. If we can agree on > how

[DISCUSS] Define CTR in Bylaws

This is a proposal to adequately describe our Commit-Then-Review process in the bylaws. I have made an initial suggestion below. If we can agree on how to make this clarification, presumably this change would be made instead of removing the Code Change action from the bylaws (or would involve add

Re: [VOTE] Accumulo Bylaws - Action changes

On Fri, Apr 4, 2014 at 10:56 AM, John Vines wrote: > The current line is unacceptable. It can also be implied that every single > code change needs to be up for review before it can be committed. It had > been contested in the last vote with no clarity on what it meant, leaving > others questioni

Re: [VOTE] Accumulo Bylaws - Action changes

I apologize for the "drama" remark. I merely sensed drama in the community and accuse no one of anything improper. Bill H On Fri, Apr 4, 2014 at 11:58 AM, Billie Rinaldi wrote: > On Fri, Apr 4, 2014 at 8:49 AM, Bill Havanki >wrote: > > > -1 > > > > Removing the line with no substitute is unacc

Re: [VOTE] Accumulo Bylaws - Action changes

That's a reasonable argument, and I won't argue with you on it. On Fri, Apr 4, 2014 at 11:56 AM, John Vines wrote: > The current line is unacceptable. It can also be implied that every single > code change needs to be up for review before it can be committed. It had > been contested in the last

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

-1 I don't think there's been sufficient discussion on this. Also, I agree with Mike back in the previous thread. The norm is for Apache to use Majority Vote for procedural changes and I'd prefer we follow suite. I have faith that our community can build consensus in a reasonable amount of time, b

Re: [VOTE] Accumulo Bylaws - Action changes

On Fri, Apr 4, 2014 at 8:49 AM, Bill Havanki wrote: > -1 > > Removing the line with no substitute is unacceptable. It can be implied > that code changes are not subject to review and/or community approval, > without the alluded-to commit and review standard in place. I doubt any > Apache project's

Re: [VOTE] Accumulo Bylaws - Action changes

The current line is unacceptable. It can also be implied that every single code change needs to be up for review before it can be committed. It had been contested in the last vote with no clarity on what it meant, leaving others questioning whether it should not be there. Yet, in spite of that, it

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

-1 My opinion on this is overly well known. On Fri, Apr 4, 2014 at 11:38 AM, Corey Nolet wrote: > +1 > > > On Fri, Apr 4, 2014 at 11:34 AM, Christopher wrote: > > > +1 > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > > > On Fri, Apr 4, 2014 at 11:33 AM, David Med

Re: [VOTE] Accumulo Bylaws - Action changes

-1 Removing the line with no substitute is unacceptable. It can be implied that code changes are not subject to review and/or community approval, without the alluded-to commit and review standard in place. I doubt any Apache project's bylaws omit the line (checked: Hadoop, HBase, Hive, ZooKeeper,

Re: [DISCUSS] Bugs-only strictness for bugfix releases

I don't know the specifics of the api changes in 1.6.0. But I would be curious, if we applied the rules of something like semver, if the version of code in the 1.6.0 branch is not consistent with the 1.6.0 version number, but is maybe a 2.0.0. - Dave - Original Message - From: dlmar

Re: [VOTE] Accumulo Bylaws - Action changes

-1 on the Vote as phrased. While I am a big supporter of the Apache notion that community is more important than code, our bylaws need to state _something_ about our policy around code changes. I like Billie's suggested move to define CtR. It does a great job of removing the ambiguity people were

Re: [VOTE] Accumulo Bylaws - Action changes

Except of course my links were bad, I meant to link to http://accumulo.apache.org/governance/lazyConsensus.html instead of voting.html. On Fri, Apr 4, 2014 at 8:40 AM, Billie Rinaldi wrote: > Let's spend a minute evaluating whether we can easily fix the issues in > the bylaws, rather than just p

Re: Release testing for 1.6.0

If we're moving into testing only and not putting more bugfixes into 1.6.0, we should really get the branches in line so that it doesn't stall development (no place to merge things). Thoughts? On 4/3/14, 1:58 PM, Sean Busbey wrote: Cloudera has finished successfully verifying a 24 hour Contin

Re: [VOTE] Accumulo Bylaws - Action changes

Let's spend a minute evaluating whether we can easily fix the issues in the bylaws, rather than just putting it off. For example, would the following changes address the problem? Index: bylaws.mdtext === --- bylaws.mdtext(revisio

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

+1 On Fri, Apr 4, 2014 at 11:34 AM, Christopher wrote: > +1 > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Fri, Apr 4, 2014 at 11:33 AM, David Medinets > wrote: > > +1 > > > > > > On Fri, Apr 4, 2014 at 11:21 AM, John Vines wrote: > > > >> This is a proposal to change

Re: [VOTE] Accumulo Bylaws - Action changes

+1 -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, Apr 4, 2014 at 11:18 AM, Josh Elser wrote: > +1 > > Minor correction, the bylaws currently state "version 0" so it should be > replaced with "version 1". > > > On 4/4/14, 11:04 AM, John Vines wrote: >> >> This is a proposal to st

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

+1 -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, Apr 4, 2014 at 11:33 AM, David Medinets wrote: > +1 > > > On Fri, Apr 4, 2014 at 11:21 AM, John Vines wrote: > >> This is a proposal to change the Bylaw Change action in the bylaws from >> Majority Approval to Consensus Approval

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

+1 On Fri, Apr 4, 2014 at 11:21 AM, John Vines wrote: > This is a proposal to change the Bylaw Change action in the bylaws from > Majority Approval to Consensus Approval. This is being requested because > Bylaw changes are a major change to the project and all discussion should > be able to be

[VOTE] Accumulo Bylaws - Bylaw Change Changes

This is a proposal to change the Bylaw Change action in the bylaws from Majority Approval to Consensus Approval. This is being requested because Bylaw changes are a major change to the project and all discussion should be able to be had without a borderline majority being able to force things thro

Re: [VOTE] Accumulo Bylaws - Action changes

+1 Minor correction, the bylaws currently state "version 0" so it should be replaced with "version 1". On 4/4/14, 11:04 AM, John Vines wrote: This is a proposal to strike the code change action from the bylaws. This is being requested because there is substantial ambiguity about the standards

[VOTE] Accumulo Bylaws - Action changes

This is a proposal to strike the code change action from the bylaws. This is being requested because there is substantial ambiguity about the standards being declared / whether this should be part of our bylaws and, until these are clarified, should be removed. Specifically, it is the following li

Re: [VOTE] Accumulo Bylaws, vote 2

The majority approval vote on version 1 of the bylaws passes. Because of the extensive discussion and vote changes, I will list each voter's final vote below. Please verify that my list is correct based on the vote's history prior to 1400 UTC (10 AM EDT / 7 AM PDT) today. Sean: +1 Bill H: +1 Eric:

Re: Review Request 20024: ACCUMULO-2627 use try-with-resources

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20024/#review39533 --- core/src/main/java/org/apache/accumulo/core/client/mapreduce/lib/ut

Re: [VOTE] Accumulo Bylaws, vote 2

Changing my vote to -0. I am personally neutral on whether we alter the document before changing its version number or vice versa, but there appears to be (informal) majority approval for fixing first. Regarding Christopher's comments, I think that using majority approval to vote to change to con

Re: [VOTE] Accumulo Bylaws, vote 2

-0 I don’t see the need to push something through that it sounds like we know we’re going to change immediately, especially given that there is opposition to the proposed bylaws. What’s the down side of waiting to get it right now? I do second Josh’s comments. Thanks Bill and everyone else fo