-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
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
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20024/#review39533
---
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
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
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
+1
On Fri, Apr 4, 2014 at 11:21 AM, John Vines vi...@apache.org 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
+1
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, Apr 4, 2014 at 11:33 AM, David Medinets
david.medin...@gmail.com wrote:
+1
On Fri, Apr 4, 2014 at 11:21 AM, John Vines vi...@apache.org wrote:
This is a proposal to change the Bylaw Change action in the bylaws from
+1
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, Apr 4, 2014 at 11:18 AM, Josh Elser josh.el...@gmail.com 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
+1
On Fri, Apr 4, 2014 at 11:34 AM, Christopher ctubb...@apache.org wrote:
+1
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, Apr 4, 2014 at 11:33 AM, David Medinets
david.medin...@gmail.com wrote:
+1
On Fri, Apr 4, 2014 at 11:21 AM, John Vines vi...@apache.org
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
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
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 billie.rina...@gmail.comwrote:
Let's spend a minute evaluating whether we can easily fix the issues in
the
-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
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:
-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,
-1
My opinion on this is overly well known.
On Fri, Apr 4, 2014 at 11:38 AM, Corey Nolet cjno...@gmail.com wrote:
+1
On Fri, Apr 4, 2014 at 11:34 AM, Christopher ctubb...@apache.org wrote:
+1
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, Apr 4, 2014 at
On Fri, Apr 4, 2014 at 8:49 AM, Bill Havanki bhava...@clouderagovt.comwrote:
-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
-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,
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 vi...@apache.org 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
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 billie.rina...@gmail.comwrote:
On Fri, Apr 4, 2014 at 8:49 AM, Bill Havanki bhava...@clouderagovt.com
wrote:
-1
On Fri, Apr 4, 2014 at 10:56 AM, John Vines vi...@apache.org 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
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
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 billie.rina...@gmail.comwrote:
This is a proposal to adequately describe our Commit-Then-Review process in
the bylaws. I have made an initial suggestion below. If
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.
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
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 vi...@apache.org
To: Accumulo Dev List
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
+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 bus...@cloudera.com
To: dev@accumulo apache. org dev@accumulo.apache.org, vi...@apache.org
Sent: Friday, April 4, 2014
+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 ke...@deenlo.com wrote:
On Fri, Mar 28, 2014 at 12:23 AM, Sean Busbey busbey+li...@cloudera.com
wrote:
Aside from the occasional stability problem, I really like the
+1 when the description is crafted to fit the prevailing CtR practice.
On Fri, Apr 4, 2014 at 12:35 PM, dlmar...@comcast.net 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 -
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 vi...@apache.org wrote:
The majority of the reasoning I read in the bylaws thread justifying why
bylaw changes should be majority and not
+1
- Original Message -
From: John Vines vi...@apache.org
To: Accumulo Dev List dev@accumulo.apache.org
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
+1 for the initial changes Billie proposed.
On Fri, Apr 4, 2014 at 12:53 PM, Sean Busbey bus...@cloudera.com wrote:
Yes, precisely.
On Fri, Apr 4, 2014 at 11:47 AM, John Vines vi...@apache.org wrote:
That makes sense, Sean. So are you saying that you think it's best to
include no
On Fri, Apr 4, 2014 at 12:12 PM, Billie Rinaldi billie.rina...@gmail.comwrote:
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
Based on the actions table, consensus
On Fri, Apr 4, 2014 at 1:06 PM, Keith Turner ke...@deenlo.com wrote:
On Fri, Apr 4, 2014 at 12:12 PM, Billie Rinaldi billie.rina...@gmail.com
wrote:
This is a proposal to adequately describe our Commit-Then-Review process
in
the bylaws. I have made
On Fri, Apr 4, 2014 at 12:06 PM, Keith Turner ke...@deenlo.com wrote:
On Fri, Apr 4, 2014 at 12:12 PM, Billie Rinaldi billie.rina...@gmail.com
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
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 vi...@apache.org wrote:
The majority of the reasoning I read in
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
On Fri, Apr 4, 2014 at 12:19 PM, John Vines vi...@apache.org 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,
On Fri, Apr 4, 2014 at 12:45 PM, Josh Elser josh.el...@gmail.com 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 Fri, Apr 4, 2014 at 1:40 PM, Alex Moundalexis al...@clouderagovt.comwrote:
On Fri, Apr 4, 2014 at 12:45 PM, Josh Elser josh.el...@gmail.com wrote:
The localized commenting on reviewboard is nice, but making updates to
the
document is definitely not fun.
Why not use GitHub? it
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
On Fri, Apr 4, 2014 at 12:49 PM, Keith Turner ke...@deenlo.com wrote:
On Fri, Apr 4, 2014 at 1:40 PM, Alex Moundalexis al...@clouderagovt.com
wrote:
On Fri, Apr 4, 2014 at 12:45 PM, Josh Elser josh.el...@gmail.com
wrote:
The localized commenting on reviewboard is nice, but making
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
-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 bus...@cloudera.com wrote:
On Fri, Apr 4, 2014 at 10:56 AM, John Vines vi...@apache.org wrote:
The current line is unacceptable. It can also be implied that
HBase has started to drop hadoop 1 support already.
On Fri, Apr 4, 2014 at 10:54 AM, John Vines vi...@apache.org 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
-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 bus...@cloudera.com wrote:
On Fri, Apr 4, 2014 at 12:19 PM, John Vines
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 mad...@cloudera.com wrote:
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 bus...@cloudera.com wrote:
Mike, as of which version is HBase dropping?
I wouldn't want
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 bus...@cloudera.com 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
On Fri, Apr 4, 2014 at 1:49 PM, Josh Elser josh.el...@gmail.com 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
On Fri, Apr 4, 2014 at 1:10 PM, John Vines vi...@apache.org 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 ke...@deenlo.com wrote:
On Fri, Apr 4, 2014 at 12:12 PM, Billie Rinaldi
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
+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 mad...@cloudera.com wrote:
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 mad...@cloudera.com 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
On Fri, Apr 4, 2014 at 1:18 PM, John Vines vi...@apache.org 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
On Fri, Apr 4, 2014 at 1:20 PM, Ravi Mutyala r...@hortonworks.com 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.
+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 unreasonable
On 4/4/14, 2:09 PM, Keith Turner wrote:
On Fri, Apr 4, 2014 at 1:49 PM, Josh Elserjosh.el...@gmail.com 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
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
+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 josh.el...@gmail.com wrote:
+1 ditto on what's been said
Not sure on how
---
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.
---
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.,
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
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
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
https://reviews.apache.org/r/20024/diff/2/?file=548734#file548734line237
ByteArrayInputStream.close() has no effect. The
---
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
68 matches
Mail list logo
