All,
It's been a few days and I haven't seen much chatter at all on
ACCUMULO-958 [1] since the patch was applied. There are a couple of
concerns I have that I definitely want to see addressed before a 1.5.0
release.
- It worries me that the provided patch is fail-open (when we can't load
Josh,
Mike Allen is still working on ACCUMULO-958, and will have an updated patch
in the next couple of weeks. We were hoping to get the more complete
encryption strategy into 1.5, but were not able to complete it by feature
freeze. However, the WAL encryption as is, when configured with the
Josh,
Mike Allen is still working on ACCUMULO-958, and will have an updated patch
in the next couple of weeks. We were hoping to get the more complete
encryption strategy into 1.5, but were not able to complete it by feature
freeze. However, the WAL encryption as is, when configured with the
Some comments about the comments in ACCUMULO-958:
Josh writes:
We still have the ability to review this even after the feature freeze
happens, it's just frustrating from my point of view in generating the best
1.5.0 candidate possible (we tend to go through x.y.0 releases pretty darn
quick).
Let me attempt to make another argument for why the 958 patch should be
included in 1.5.0. What this patch represents is not an encryption solution
for WAL, but an experimental extension point that will be used for building
an encryption solution as a pluggable module. We need to judge its merit
Bottom line, the patch has no value added to general users. The idea behind
pushing back a release date to stuff in unoperational code is very bad
practice. It sets a precedent for not considering alternative approaches
while simultaneously having no justification for choosing the approach we
did.
On Wed, Jan 30, 2013 at 10:40 AM, Adam Fuchs afu...@apache.org wrote:
Let me attempt to make another argument for why the 958 patch should be
included in 1.5.0. What this patch represents is not an encryption solution
for WAL, but an experimental extension point that will be used for building
Was this resolved?
On Mon, Jan 28, 2013 at 8:28 AM, David Medinets
david.medin...@gmail.com wrote:
I had a plain Java program, single-threaded, that read an HDFS
Sequence File with fairly small Sqoop records (probably under 200
bytes each). As each record was read a Mutation was created, then
Can we use the Accumulo wiki to kind of collect these feature requests into a
place where they are easier to see, avoid duplication, and identify overlaps /
convergent feature requests?
On Jan 30, 2013, at 12:22 PM, Adam Fuchs afu...@apache.org wrote:
On Tue, Jan 29, 2013 at 12:40 PM,
Perhaps another option - it's not uncommon for a company, like Cloudera or
RedHat, to add patches to their distribution for things they want to roll out
earlier than the broader community wants them, among other reasons. Companies
also often backport newer features to older releases.
Although
That works too. It'd be much better than distributing the features throughout
the dev list amidst lots of text about where to put the list of features.
On Jan 30, 2013, at 1:28 PM, Keith Turner ke...@deenlo.com wrote:
On Wed, Jan 30, 2013 at 1:20 PM, Aaron Cordova aa...@cordovas.org wrote:
On Wed, Jan 30, 2013 at 1:30 PM, Aaron Cordova aa...@cordovas.org wrote:
That works too. It'd be much better than distributing the features throughout
the dev list amidst lots of text about where to put the list of features.
Agreed. Also, if you create new tickets for things you want in 1.6
Bill,
The release date was not pushed back just for this ticket -- there were
several other changes that motivated that date change. We can discuss that
aspect separately from a discussion of ACCUMULO-958, and we need to start a
separate thread to talk about the remaining milestones before the
On Wed, Jan 30, 2013 at 1:45 PM, Adam Fuchs scubafu...@gmail.com wrote:
Bill,
The release date was not pushed back just for this ticket -- there were
several other changes that motivated that date change. We can discuss that
aspect separately from a discussion of ACCUMULO-958, and we need to
I don't have any concerns with releasing features in 1.5.1, but please be
cognizant that the intent of
ACCUMULO-751https://issues.apache.org/jira/browse/ACCUMULO-751was
for wire compatibility across the 1.5.X series.
I'll strongly agree with Keith regarding a stable API - confusing and
constantly
(For the record, when I say useless, I mean javadoc comments that consist
solely of the auto-generated skeleton, derived from the method signature,
with little or nothing added)
In our code template, we add javadoc tags to new methods, classes, etc. I
think this is a good idea... except that this
One of the things I notice while doing a large amount of refactoring was
the pain of having to be careful about updating javadoc comments. Is it
possible to enforce comments corresponding to actual method calls? It's not
perfect but our would help.
Sent from my phone, please pardon the typos and
I'm not sure what you mean by enforce, but it's a simple matter to tell
Eclipse to produce a warning on malformed javadocs (which includes @param
tags that don't match actual parameters), and I believe there's also an
option to add and/or warn about missing @param tags, as well as a bunch of
other
+1
I avoid method-level documentation unless something surprising is going on.
On Wed, Jan 30, 2013 at 7:56 PM, Christopher ctubb...@apache.org wrote:
(For the record, when I say useless, I mean javadoc comments that consist
solely of the auto-generated skeleton, derived from the method
+1 for more shell command to simplify.
On Jan 30, 2013 6:08 PM, Christopher ctubb...@apache.org wrote:
I was going to add a warning to aggregators and filters, for the setiter
shell command (for ACCUMULO-953), but it looks like a warning was already
added for aggregators, and filters are no
Given the discussion that's taken place today on this thread, I'd like
to bring back around the discussion and refocus my concerns, given
everyone else's comments, and perhaps generate some sort of summary,
boiling down to what next.
First, my own opinions, despite how my actions may/may not
21 matches
Mail list logo
