I definitely agree with #1. Still pondering #2.
On Tue, May 6, 2014 at 1:58 PM, Christopher ctubb...@apache.org wrote:
Devs,
As something that came out of the vote thread about EOL'ing 1.4, I was
thinking:
The purpose of a majority vote seems to be when we've already
discussed and
On May 15, 2014, 1:53 p.m., kturner wrote:
Ship It!
I was concerned about wider sharing of zoocache objects than before AND calls
to zoocahce.clear(). Looking at the code it seems that most of the code that
calls zoocache.clear() creates its own zoocache via new zoocache. So the
code
I like that flow.
I'm very much against not letting contributors assign tickets. If you have a
problem with old contributors stealing tickets from new contributors, then
that needs to be handled with best practices documentation and/or explicit
coaching. Locking down who can assign tickets is
As a contributor, I like this approach. I'm able to through and assign an
issue to myself without pestering anyone else.
I like the incentive-based approach for prospective contributors: have a
committer assign an issue to a user after they express interest in working
it, then give them
The last paragraph, is it:
a) an instruction to work on the 1.4 line?
b) saying that work on the 1.4 line will cease?
On Wed, May 7, 2014 at 11:50 AM, Sean Busbey busbey+li...@cloudera.comwrote:
Presented for feedback / discussion: draft ANNOUNCE message for the
user@accumulo list.
I think
It seems like a simple solution to that is some documentation on our web
site encouraging people to contact
the person a ticket is assigned to if
they are interested in working on it.
+1
--
Joey Echeverria
Chief Architect
Cloudera Government Solutions
On Fri, May 16, 2014 at 9:46 AM,
On 5/11/14, 12:22 AM, James Taylor wrote:
@William - it's entirely possible that my HBase terminology is not mapping
well to Accumulo terminology. If Accumulo has a capability not present in
HBase that'll handle this, that'd be great.
In HBase terminology, by row I mean all of the key values
Looking at the ticket you linked it seems it easy for infra to make this
change. As long as its not a hassle for infra I would be in favor of
changing it back.
The problem w/ issues being assigned to people who are not working on them
(it seems this is sparks concern) applies to commiters and
+1 for restoring old behavior.Why wouldn't we allow contributors to help
themselves help the community?
On Thu, May 15, 2014 at 11:13 AM, John Vines vi...@apache.org wrote:
Yes, restore the old behavior
On Wed, May 14, 2014 at 4:38 PM, Sean Busbey bus...@cloudera.com wrote:
We don't have
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21557/#review43223
---
Correction: the current patch does *NOT* bump the wire version... I
thought I did that, but I did not.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, May 16, 2014 at 12:28 PM, Christopher ctubb...@apache.org wrote:
Devs,
I'm considering whether or not it'd be appropriate to
On May 16, 2014, 5:30 p.m., John Vines wrote:
server/tserver/src/main/java/org/apache/accumulo/tserver/log/DfsLogger.java,
line 153
https://reviews.apache.org/r/21557/diff/1/?file=583591#file583591line153
I think that before this loop the closeLock and/or closed should be
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21557/
---
Review request for accumulo.
Bugs: ACCUMULO-2766
Do we know if thirft 0.9.0 and 0.9.1 are forward compatible?
On Fri, May 16, 2014 at 12:59 PM, Christopher ctubb...@apache.org wrote:
Correction: the current patch does *NOT* bump the wire version... I
thought I did that, but I did not.
--
Christopher L Tubbs II
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21567/#review43255
---
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21072/#review43106
---
Ship it!
Ship It!
- kturner
On May 5, 2014, 2:23 p.m., Bill
What was the reasoning behind the change?
On Wed, May 14, 2014 at 4:38 PM, Sean Busbey bus...@cloudera.com wrote:
We don't have a formal onboarding process for drawing in new contributors,
but a recent ASF Infra change impacts what I've observed historically.
Here's what I've seen
On May 16, 2014, 8:19 p.m., Josh Elser wrote:
server/tserver/src/test/java/org/apache/accumulo/tserver/log/LocalWALRecoveryTest.java,
line 75
https://reviews.apache.org/r/21567/diff/1/?file=583640#file583640line75
Wouldn't it have simplified things to just use the
Yes, restore the old behavior
On Wed, May 14, 2014 at 4:38 PM, Sean Busbey bus...@cloudera.com wrote:
We don't have a formal onboarding process for drawing in new contributors,
but a recent ASF Infra change impacts what I've observed historically.
Here's what I've seen historically, more or
I'd like to look into the level of effort to allow the Overview server (
https://www.overviewproject.org/) to pull text directly from Accumulo. This
tools seems like a natural fit with the TedgeText table in the D4M schema.
Is there a way to write Java code to redistribute tablets across all tablet
servers? I've come across the TabletBalancer class in 1.5 and I'm currently
trying to utilize it to evenly redistribute all of the tablets because they
are clustered onto one tablet server. Is there an easier way to do
On May 16, 2014, 9:13 p.m., Mike Drob wrote:
server/tserver/src/main/java/org/apache/accumulo/tserver/log/DfsLogger.java,
line 302
https://reviews.apache.org/r/21567/diff/1/?file=583638#file583638line302
Was this a copy/paste error?
it looks like it was an error in handling
Yes. They are 100% forward/backwards compatible on the wire.
However, it is my understanding that there were some minor additions
(new API) to 0.9.1 which won't work in 0.9.0... but that won't affect
us since we are not using those features (and wouldn't be adding
anything that leverages those
On May 16, 2014, 8:19 p.m., Josh Elser wrote:
server/tserver/src/test/java/org/apache/accumulo/tserver/log/LocalWALRecoveryTest.java,
line 75
https://reviews.apache.org/r/21567/diff/1/?file=583640#file583640line75
Wouldn't it have simplified things to just use the
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21567/#review43266
---
Ship it!
On May 16, 2014, 5:30 p.m., John Vines wrote:
server/tserver/src/main/java/org/apache/accumulo/tserver/log/DfsLogger.java,
line 153
https://reviews.apache.org/r/21557/diff/1/?file=583591#file583591line153
I think that before this loop the closeLock and/or closed should be
You have a blog account (medined). You will probably need to submit an INFRA
ticket to get the password reset.
- Original Message -
From: David Medinets david.medin...@gmail.com
To: accumulo-dev dev@accumulo.apache.org
Sent: Friday, May 9, 2014 10:39:43 AM
Subject: Accumulo Blog
Kite's already integrated into Spring XD, so I was hoping that by getting
things together there we'd have an easier time wiht things like Spring XD
On Fri, May 9, 2014 at 2:33 PM, David Medinets david.medin...@gmail.comwrote:
https://github.com/spring-projects/spring-xd is the project's page.
Infra noted a 1.5M long email queue for sending to gmail, so I think it's the
interaction between the two. --
Joey Echeverria
Chief Architect
Cloudera Government Solutions
On Fri, May 16, 2014 at 4:06 PM, Sean Mackrory mackror...@gmail.com
wrote:
I've been seeing delays, and another user on
Until we have problems with it, I would prefer that contributors could
continue to assign things as they see fit.
Their contributor status implies that they are at least somewhat
acclimated with our processes and that they have a positive opinion of
the project.
On 5/14/14, 4:38 PM, Sean
On May 16, 2014, 7:11 p.m., Mike Drob wrote:
server/tserver/src/main/java/org/apache/accumulo/tserver/log/DfsLogger.java,
line 150
https://reviews.apache.org/r/21557/diff/1/?file=583591#file583591line150
Should explicitly handle InvocationTargetException. Can be done in a
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21282/#review42605
---
the default balancer should already handle moving the tablets across all
servers.
Check the master's debug log to see if there are messages about trouble
with balancing. For example, if there are unhosted tablets then the master
won't rebalance tablets.
If you have one or more offline tables,
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21282/
---
(Updated May 9, 2014, 11:39 p.m.)
Review request for accumulo.
Changes
On May 16, 2014, 8:19 p.m., Josh Elser wrote:
server/tserver/src/test/java/org/apache/accumulo/tserver/log/LocalWALRecoveryTest.java,
line 75
https://reviews.apache.org/r/21567/diff/1/?file=583640#file583640line75
Wouldn't it have simplified things to just use the
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21557/
---
(Updated May 16, 2014, 10:56 p.m.)
Review request for accumulo.
Changes
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21169/
---
(Updated May 7, 2014, 11:33 p.m.)
Review request for accumulo, Sean Busbey and
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21567/#review43298
---
Test now passes for me
- Josh Elser
On May 16, 2014, 11:29 p.m.,
That sounds promising, Josh William. Is there a performance penalty with
this approach (versus traversing the rows in row key order)?
Thanks,
James
On Fri, May 16, 2014 at 8:27 AM, Josh Elser josh.el...@gmail.com wrote:
On 5/11/14, 12:22 AM, James Taylor wrote:
@William - it's entirely
On May 16, 2014, 8:19 p.m., Josh Elser wrote:
server/tserver/src/test/java/org/apache/accumulo/tserver/log/LocalWALRecoveryTest.java,
line 75
https://reviews.apache.org/r/21567/diff/1/?file=583640#file583640line75
Wouldn't it have simplified things to just use the
That looks like an accurate representation of the informal process.
+1 for letting them assign themselves
Aside about #7: If this process gets documented in a contributor
section of the website (which, maybe it should?) or a wiki, or
whatever, I'd want to just add note that when looking for
Devs,
I'm considering whether or not it'd be appropriate to push in
ACCUMULO-1691 into the 1.6.1-SNAPSHOT branch.
This would effectively bump our dependency on libthrift to 0.9.1.
However, thrift 0.9.1 and 0.9.0 are 100% wire-compatible (I've been
assured by jfarrell and codesf in the #thrift IRC
42 matches
Mail list logo
