If we do it early and are prepared to revert if we find we come into a
situation we cannot work around, then I'd be +1 to pursuing 0.9.2
(even though I was kinda happy I only needed to keep one version
installed now that we're not really making 1.5 releases any more).
--
Christopher L Tubbs II
htt
Yeah, that's why I brought it up now. If we're going to do it, we should
do it now and let the shake-down begin.
I know Hive has been on 0.9.2 for a while now, so I assume it's somewhat
ok. I'm sure we'll be good testers :)
Christopher wrote:
Bumping thrift versions scares me... a lot... bec
GitHub user ctubbsii opened a pull request:
https://github.com/apache/accumulo/pull/40
ACCUMULO-3920 Deprecate mock components
== Done so far ==
* Deprecate Accumulo Mock classes
* Add javadoc to mock package to add additional details
* Create `DeprecationUtil` to he
Bumping thrift versions scares me... a lot... because of how terrible
thrift has been about avoiding breakage and/or retaining
functionality. It seems every time we bump to fix something we want
fixed, we find many more things broken.
I'd be much more interested in moving to something a bit more r
I completely agree with more abstracting separable funtionality where
it makes sense. I think RFile makes sense. Maybe separating it out
would help alleviate some problems I've seen with it being too tightly
coupled with Hadoop config and Accumulo config. And, maybe it'd help
with its API... right
Also, might be worthwhile to look at thrift 0.9.2 for 1.8
For kerberos, https://issues.apache.org/jira/browse/THRIFT-2660.
https://issues.apache.org/jira/browse/THRIFT-2274 might be a concern for
us too (would have to check).
Josh Elser wrote:
Some thoughts myself...
John Vines brought up t
Some thoughts myself...
John Vines brought up to me privately the topic of separating out the
RFile code from core. This started making me think about making this
clear for other components like FATE and RandomWalk. These all have some
level of separation, but they often get other things dropp
I don't see a problem sending an extra note to the user@ alias and the
twitter, just to be clear but I think we've sufficiently covered it
for the larger ASF community with the announce@ notice.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jul 8, 2015 at 12:58 PM, Josh Elser w
Do you think we didn't cover that appropriately in the ANNOUNCE email
and/or the release notes?
I wouldn't have expected anything more from Hadoop Weekly than "apache
foo x.y.z, 1-2 high-level changes, read more _here_"
Sean Busbey wrote:
I think we also need a formal announcement that the b
[insert Dilbert awkward happy dance comic]
This is the result of my most recent map-reduce test run on 10-node amazon
cluster.
Thanks to Josh for working on test stability with me. Thank you for
everyone who has contributed tests that let me make sweeping changes with
some confidence.
PASS
or
I think we also need a formal announcement that the branch is EOM and may
only be resuscitated for critical security issues (and may not at that).
To illustrate the need, I noticed the 1.5.3 release made Hadoop Weekly but
there was no mention that it is the last expected 1.5.z release.
On Tue, Ju
11 matches
Mail list logo
