Re: [DISCUSS] Jenkins notifications to dev list?

her > developer-related knowledge. > > I don't see why we can't present it with the caveats you state. It feels > like we're starting a boys-club if we have something we're going to rely > upon for development that we don't tell anyone about... > > Christopher wrote:

Re: [DISCUSS] Jenkins notifications to dev list?

hu, Jul 14, 2016 at 3:57 PM Josh Elser <josh.el...@gmail.com> wrote: > Bueno. Makes sense to me and avoids future issues with that lengthy > disclaimer you sent previously :) > > Maybe have something on the website for contributors/new-devs to find > out about too? > > Chri

Re: [DISCUSS] Jenkins notifications to dev list?

, Jul 14, 2016 at 2:48 PM Josh Elser <josh.el...@gmail.com> wrote: > Yeah, that's a decent intermediate step. Getting an email is pretty much > the only thing that's going to force me to pay attention. > > Making it self-service would be an even bigger plus, but I'm OK waiting

Re: [DISCUSS] Jenkins notifications to dev list?

> > motivates us to not break the tests and make the tests stable. I'll > leave > > it to your decision Chris, unless others have an opinion. > > > > On Wed, Jul 13, 2016 at 8:54 PM, Christopher <ctubb...@apache.org> > wrote: > > > > > On Wed

Re: [DISCUSS] Jenkins notifications to dev list?

On Wed, Jul 13, 2016 at 11:02 PM Dylan Hutchison <dhutc...@cs.washington.edu> wrote: > On Wed, Jul 13, 2016 at 4:36 PM, Christopher <ctubb...@apache.org> wrote: > > > Okay, so after some investigation ( > > https://issues.apache.org/jira/browse/INFRA-12252), it

Re: ChangeSecret Utility

n/accumulo org.apache.accumulo.server.util.ChangeSecret This would imply that the thing which is interfering is something coming in from the classpath which is set up by bin/accumulo. On Wed, Jul 13, 2016 at 6:27 PM Christopher <ctubb...@apache.org> wrote: > The shell does change the input charset (to latin1, I believe),

Re: ChangeSecret Utility

ce of 1.7.2 setup on my machine. I am > running > >>>> the > >>>> utility as myself, which is also the user that is running Hadoop and > who > >>>> has control over the files in HDFS, but when the utility prompts for > the > >>>> pass

Re: Board report draft July 2016

I'm interested in doing a 1.6.6 after 1.8.0 is released, just so we can do a final bugfix before EOL 1.6. Not sure that's noteworthy for the report, though. On Wed, Jul 13, 2016, 11:04 Billie Rinaldi wrote: > I found one parenthetical mention of the idea of a 1.6.6

Jenkins disclaimer

I just had an interesting conversation with some folks in HipChat #asfinfra. As follow-up from that dialogue, I just want to clarify: The build/CI server I'm running at https://jenkins.revelc.net is not affiliated with ASF in any way, and is not part of Apache's infrastructure. Nor is it under

Re: [DISCUSS] Htrace4, Hadoop 2.7

On Fri, Jul 8, 2016 at 5:05 PM Sean Busbey <bus...@cloudera.com> wrote: > On Fri, Jul 8, 2016 at 3:40 PM, Christopher <ctubb...@apache.org> wrote: > > On Fri, Jul 8, 2016 at 11:20 AM Sean Busbey <bus...@cloudera.com> wrote: > >> Would we be bumping the Hadoop

Re: [DISCUSS] Htrace4, Hadoop 2.7

m for them. > I am not sure if anyone is using it or not. > > Billie > > On Thu, Jul 7, 2016 at 2:42 PM, Christopher <ctubb...@apache.org> wrote: > > > Ah, my mistake. I thought it was 2.7 and later. Well, then I guess the > > question is whether we should bump to

Re: [DISCUSS] Htrace4, Hadoop 2.7

p 2.8 and later.) > > Billie > > On Thu, Jul 7, 2016 at 2:20 PM, Christopher <ctubb...@apache.org> wrote: > > > Thinking about https://issues.apache.org/jira/browse/ACCUMULO-4171, I'm > of > > the opinion that we should probably bump our Hadoop version to 2.7 and >

[DISCUSS] Htrace4, Hadoop 2.7

Thinking about https://issues.apache.org/jira/browse/ACCUMULO-4171, I'm of the opinion that we should probably bump our Hadoop version to 2.7 and HTrace version to what Hadoop is using, to keep them in sync. Does anybody disagree?

Re: [DISCUSS] Proposed binary packaging changes

I assume you mean pull request. (JIRA link is below). Will do. On Tue, Jul 5, 2016, 19:43 Sean Busbey <bus...@cloudera.com> wrote: > Sounds good. Please post a link here to the JIRA? > > > > On Tue, Jul 5, 2016 at 4:58 PM, Christopher <ctubb...@apache.org> wrote: >

Re: [DISCUSS] Proposed binary packaging changes

On Thu, Jun 30, 2016 at 5:43 PM Christopher <ctubb...@apache.org> wrote: > Hi all, > > I'd like to bring to your attention > https://issues.apache.org/jira/browse/ACCUMULO-4356, for discussion. Feel > free to comment here or on the issue. > Reading back through all

Re: ACCUMULO-1604 Bug Fix

On Tue, Jul 5, 2016 at 11:50 AM Mike Miller wrote: > Is > there a preferred technique of code submission for non-committers? > > My personal preference: GitHub pull requests. :)

Re: [DISCUSS] Proposed binary packaging changes

On Fri, Jul 1, 2016 at 3:07 PM William Slacum wrote: > Is another action we could take be adding profiles for each version of > dependencies to include appropriate dependencies (and dependencies' > metadata)? > > That could be a potentially huge number of profiles, and it

Re: [DISCUSS] Proposed binary packaging changes

only > a source-release. > > If this is *really* about ease-of-use for downstream packagers (which > seemed to be your original intent, Christopher), is there a different > way we could solve this problem that would meet your needs (again, > assuming you're trying to make li

Re: [DISCUSS] Proposed binary packaging changes

till doing binary tarball but with less bundling had a better chance at getting buy-in. > > On Thu, Jun 30, 2016 at 8:03 PM, Christopher <ctubb...@apache.org> wrote: > > > > The impetus for this was that I recently bumped our commons-math > dependency > > to commo

Re: [DISCUSS] Proposed binary packaging changes

. > Projects like accumulo-quickstart(1) are critical for allowing users to > play around with Accumulo at low entry barrier. Let's make sure that (or a > similar) project still works. > > Agreed. > (1) https://github.com/accumulobook/quickinstall > (Pending PR) https://

[DISCUSS] Proposed binary packaging changes

Hi all, I'd like to bring to your attention https://issues.apache.org/jira/browse/ACCUMULO-4356, for discussion. Feel free to comment here or on the issue.

Re: ClientConfiguration doesn't check classpath

On Thu, Jun 30, 2016 at 11:13 AM Mike Drob <mad...@cloudera.com> wrote: > On Wed, Jun 29, 2016 at 5:24 PM, Christopher <ctubb...@apache.org> wrote: > > > To get rid of the warning, don't use ClientConfiguration.loadDefault(). > > Unit tests should be self-con

Re: ClientConfiguration doesn't check classpath

y be nice when you > want to interact with multiple instances from the same host (thus requiring > different client confs). > > Christopher's #1 point would also be a similar solution to the same > problem. I'm not sure if one or the other would be better/worse. > On Jun 29, 2016 3:

Re: ClientConfiguration doesn't check classpath

To get rid of the warning, don't use ClientConfiguration.loadDefault(). Unit tests should be self-contained, and not use the user's environment. Instead, use "new ClientConfiguration()". If you're still getting that warning, we need to fix it. That constructor shouldn't be reading any external

Re: [ANNOUNCE] Apache Accumulo 1.7.2 Released

Minor correction: this release is version 1.7.2 :) On Thu, Jun 23, 2016 at 11:47 AM Mike Drob wrote: > The Accumulo team is proud to announce the release of Accumulo version > 1.7.1! > > This release contains over 30 bugfixes and improvements over 1.7.1, and is >

Re: [RESULT] [VOTE] Accumulo 1.7.2-rc2

On Wed, Jun 22, 2016 at 6:21 PM Mike Drob wrote: > This vote passes with 5 +1. > > Maven repository has been promoted. > Release tag has been pushed, but this is the wrong one. See INFRA-12153. > This has been fixed. I was in HipChat earlier and nagged a bit. Infra unlocked the

Re: [VOTE] Accumulo 1.7.2-rc2

Haven't added up the sum, but my guess is that this vote passed. Mike has already started working on tagging/publishing artifacts, but ran into a snag when the wrong branch was unintentionally tagged. Waiting on INFRA for https://issues.apache.org/jira/browse/INFRA-12153 On Mon, Jun 20, 2016 at

Re: [VOTE] Accumulo 1.7.2-rc2

+0 * Verified all hashes, sigs * Unit tests and ITs all pass (org.apache.accumulo.test.BadDeleteMarkersCreatedIT.test timed out the first time, but passed on re-run) * Verified contents of bin tarball match jars in staging repo and src tarball match rc branch in git My only concern would be that

Re: [VOTE] Accumulo 1.7.2-rc2

other one. A similar > question then, Christopher. Do we need to remove all the individual project > lines? > > On Mon, Jun 20, 2016 at 11:31 AM, Christopher <ctubb...@apache.org> wrote: > > > On Sun, Jun 19, 2016 at 9:26 PM Josh Elser <els...@apache.org> wrote: &

Re: [VOTE] Accumulo 1.7.2-rc2

> deps > > <http://pastebin.com/HJZB2See>, and a pastebin for the binary > artifact > > deps<http://pastebin.com/nKfxWd2c> for accumulo-core.jar. Here is > > a pastebin > > of their diff<http://pastebin.com/jYtggRLK>. I don't know how >

Re: [VOTE] Accumulo 1.7.2-rc1

On Fri, Jun 17, 2016, 22:18 Sean Busbey <bus...@cloudera.com> wrote: > On Fri, Jun 17, 2016 at 5:21 PM, Christopher <ctubb...@apache.org> wrote: > > > > > > Sean, I noticed you committed the change you wanted to the LICENSE files, > > in spite of my

Re: [VOTE] Accumulo 1.7.2-rc1

On Fri, Jun 17, 2016 at 4:30 PM Christopher <ctubb...@apache.org> wrote: > On Fri, Jun 17, 2016 at 3:28 PM Josh Elser <josh.el...@gmail.com> wrote: > >> >> >> Mike Drob wrote: >> > Thanks for taking a look, Sean. >> > >> > T

Re: [RESULT] [VOTE] Accumulo 1.7.2-rc1

I recommend preserving the staging repository until the final release. It's useful to compare between different RCs. On Fri, Jun 17, 2016 at 4:38 PM Mike Drob wrote: > This vote fails with one +1, one -1, and one +1 after the deadline. > > The staging repository will be dropped

Re: [VOTE] Accumulo 1.7.2-rc1

On Fri, Jun 17, 2016 at 3:28 PM Josh Elser wrote: > > > Mike Drob wrote: > > Thanks for taking a look, Sean. > > > > The LICENSE file in the source tarball refers to the BSD license and > > includes "for details see > >

Re: [VOTE] Accumulo 1.7.2-rc1

e a JIRA to update the build script output? > > Mike > > On Thu, Jun 16, 2016 at 3:01 PM, Christopher <ctubb...@apache.org> wrote: > > > Mike, did you intend to sign with your GPG key whose fingerprint is: > > 6A90F817481A73C1C419B62D8F2F220786C4FB2A &g

Re: [VOTE] Accumulo 1.7.2-rc1

Mike, did you intend to sign with your GPG key whose fingerprint is: 6A90F817481A73C1C419B62D8F2F220786C4FB2A or 86EDB9C33B8517228E88A8F93E48C0C6EF362B9E ? The build.sh script seemed to have put two in the email template, probably because you have two GPG keys. I noticed that they were signed

Re: Apache Accumulo integrated with Presto

Thanks for that summary, Dylan! Very helpful. On Mon, Jun 13, 2016, 01:36 Dylan Hutchison wrote: > Thanks for sharing Sean. Here are some notes I wrote after reading the > article on Presto-Accumulo design. I have a research interest in the > relationship between

Re: Bigger Jenkins

you to the revelc organization on GitHub and place you on the jenkins-users team. That will grant you access. On Fri, Jun 3, 2016 at 2:43 PM Christopher <ctubb...@apache.org> wrote: > Devs, > > I set up a slightly beefier Jenkins than the one Josh had running > (hopefully, it's

PDF build dependencies for CentOS 7

In case anybody needs to build the PDF doc in the 1.6 branch, you need to do this on CentOS 7: sudo yum install lexlive texlive-multirow texlive-ulem Hopefully we won't have too many more releases which require LaTeX.

Re: Bigger Jenkins

uming we've gotten the full IT suite to pass at least twice before. > > mvn verify -Dforkcount=2 > > On Fri, Jun 3, 2016 at 1:43 PM, Christopher <ctubb...@apache.org> wrote: > > > Devs, > > > > I set up a slightly beefier Jenkins than the one Josh had running > &g

Bigger Jenkins

Devs, I set up a slightly beefier Jenkins than the one Josh had running (hopefully, it's big enough to have tests consistently pass). I don't have much set up on it right now, just one job. Things to do: 1. create more jobs for various branches 2. Determine appropriate scheduling 3. figure out

Re: Minimum supported Hadoop?

Yes, I believe so. Good point. On Fri, Jun 3, 2016, 00:15 Mike Drob <md...@mdrob.com> wrote: > The ITs pass on certain Java versions, right? We can doc that and iterate > from there. > On Thu, Jun 2, 2016 at 11:09 PM Christopher <ctubb...@apache.org> wrote: > > >

Re: Minimum supported Hadoop?

: > I would not feel comfortable bumping the min req Hadoop in 1.7.2 > > On Wed, Jun 1, 2016 at 6:39 PM Christopher <ctubb...@apache.org> wrote: > > > Perhaps. But the tests pass with 2.6.1, I think. Shouldn't be that much > > different in terms of support, so I figur

Re: Hadoop

he Hadoop packages like Zookeeper and Parquet. > > On Thu, Jun 2, 2016 at 4:59 PM, Christopher <ctubb...@fedoraproject.org> > wrote: > > > That first post was intended for the Fedora developer list. Apologies for > > sending to the wrong list. > > > >

Re: Hadoop

PM Christopher <ctubb...@fedoraproject.org> wrote: > Sorry, wrong list. > > On Thu, Jun 2, 2016 at 4:20 PM Christopher <ctubb...@fedoraproject.org> > wrote: > >> So, it would seem at some point, without me noticing (certainly my fault, >> for not paying att

Re: Hadoop

Sorry, wrong list. On Thu, Jun 2, 2016 at 4:20 PM Christopher <ctubb...@fedoraproject.org> wrote: > So, it would seem at some point, without me noticing (certainly my fault, > for not paying attention enough), the Hadoop packages got orphaned and/or > retired? in Fedora. &g

Hadoop

So, it would seem at some point, without me noticing (certainly my fault, for not paying attention enough), the Hadoop packages got orphaned and/or retired? in Fedora. This is a big problem for me, because the main package I work on is dependent upon Hadoop. What's the state of Hadoop in Fedora

Re: Minimum supported Hadoop?

.el...@gmail.com> wrote: > For that reasoning, wouldn't bumping to 2.6.4 be better (as long as > Hadoop didn't do anything screwy that they shouldn't have in a > maintenance release...) > > I have not looked at deltas between 2.6.1 and 2.6.4 > > Christopher wrote: > > I w

Minimum supported Hadoop?

I was looking at the recently bumped tickets and noticed https://issues.apache.org/jira/browse/ACCUMULO-4150 It seems to me that we may want to make our minimum supported Hadoop version 2.6.1, at least for the 1.8.0 release. That's not to say it won't work with other versions... just that it's

Jar sealing

Devs- There's been a few issues with jar sealing that I've run into lately. Some of which only occurred doing test RC builds. To make these issues more prominent, I recently made the maven-jar-plugin always do jar sealing, so we can catch these issues earlier, as part of a pom/build update to use

Re: Fwd: Accumulo-Test-1.6-Hadoop-1 - Build # 1032 - Failure!

Should be fixed now. Looks like I had already done this with the 1.8 branch at one point, but not in the old ones. On Fri, May 27, 2016 at 11:58 AM Josh Elser <josh.el...@gmail.com> wrote: > Thanks :) > > Christopher wrote: > > Oh, crap, I messed up jar sealing (didn't notic

Re: [DISCUSS] Time for a 1.8.0 release?

, "Michael Wall" <mjw...@gmail.com> wrote: > > > Didn't get a chance to talk to Christopher so hopefully what I understood > > from emails with Josh and him is correct. > > > > Moved issues out of 1.8.0. Here is a summary of the fix version changes &g

Re: Fwd: Accumulo-Test-1.6-Hadoop-1 - Build # 1032 - Failure!

Oh, crap, I messed up jar sealing (didn't notice because we normally skip tests during a release, and we previously only sealed jars during a release). I will fix that later today. On Fri, May 27, 2016 at 3:05 AM Christopher <ctubb...@apache.org> wrote: > Hmm. I tested all of them.

Re: Fwd: Accumulo-Test-1.6-Hadoop-1 - Build # 1032 - Failure!

Hmm. I tested all of them. The PIAB builds were already failing... but I'll look at it later today. On Fri, May 27, 2016 at 2:13 AM Josh Elser wrote: > Correction, all of 1.6 and 1.7 appear busted after Christopher's asf pom > version update. > On May 26, 2016 11:11 PM,

Re: [DISCUSS] Time for a 1.8.0 release?

If you wanted to go ahead and get started, you could cut an RC0 (non-voting) to test. assemble/build.sh is very helpful for this Also, I'm about to update ACCUMULO-4312 On Thu, May 26, 2016 at 8:57 PM Michael Wall <mjw...@gmail.com> wrote: > Didn't get a chance to talk to Chris

Re: Jira/GitHub spam reduction thoughts

https://issues.apache.org/jira/browse/INFRA-11984 On Thu, May 26, 2016 at 8:38 PM Billie Rinaldi <billie.rina...@gmail.com> wrote: > On Thu, May 26, 2016 at 5:19 PM, Christopher <ctubb...@apache.org> wrote: > > > Billie, are you able to make this change, or should

Re: Jira/GitHub spam reduction thoughts

Billie, are you able to make this change, or should I file an INFRA ticket? On Tue, May 24, 2016 at 4:10 PM Christopher <ctubb...@apache.org> wrote: > On Tue, May 24, 2016 at 10:46 AM Billie Rinaldi <billie.rina...@gmail.com> > wrote: > >> On Mon, May 23, 2016 at

Re: [DISCUSS] Release 1.7.2

+1 for releasing a 1.7.2 (and even a 1.6.6) in short order. On Thu, May 26, 2016 at 1:14 PM Keith Turner wrote: > On Thu, May 26, 2016 at 1:04 PM, Sean Busbey wrote: > > > Do the folks assigned to those issues believe they'll be ready by e.g. > >

Re: [DISCUSS] Time for a 1.8.0 release?

On Sun, May 22, 2016 at 9:42 PM Michael Wall <mjw...@gmail.com> wrote: > After last weeks discussion with Josh, Christopher and others at the > Accumulo Working Day, I am going to shepherd the 1.8 release. First step > is to create a release candidate? Before I do that, are th

Re: Jira/GitHub spam reduction thoughts

On Tue, May 24, 2016 at 10:46 AM Billie Rinaldi <billie.rina...@gmail.com> wrote: > On Mon, May 23, 2016 at 9:43 PM, Christopher <ctubb...@apache.org> wrote: > > > Okay, so after all that work I did on > > https://issues.apache.org/jira/browse/INF

Re: Jira/GitHub spam reduction thoughts

that users could have a bit more control over their subscriptions. On Tue, May 24, 2016 at 12:43 AM Christopher <ctubb...@apache.org> wrote: > Okay, so after all that work I did on > https://issues.apache.org/jira/browse/INFRA-11675 , we were able to get > the duplicate messages on th

Jira/GitHub spam reduction thoughts

Okay, so after all that work I did on https://issues.apache.org/jira/browse/INFRA-11675 , we were able to get the duplicate messages on the notifications list to stop, which came from comments on GitHub pull requests which also triggered emails about comments from JIRA. However, it now appears

Re: Co-working group on May 17th

until yesterday). On Thu, May 19, 2016 at 11:42 PM Josh Elser <josh.el...@gmail.com> wrote: > I forgot to mention earlier that a small number of us got together on > the 17th to work in proximity to each other. > > Myself, Billie, Keith, Mike Wall, Mike Walch, and Christop

Re: Accumulo on s3

getWalDirs() is used only in legacy code intended to ease upgrades from 1.4.x to 1.5.x. It probably has no value in the current code, as I'm not sure we've even tested upgrades from 1.4.x to 1.7.x. On Thu, May 12, 2016 at 11:03 AM Shawn Walker wrote: > Teng Qiu, > > I

Re: Pros and Cons of moving SKVI to public API

Hey Keith. Just wanted to ping you on this to see if you've had a chance to look. On Fri, Mar 25, 2016 at 12:17 PM Keith Turner <ke...@deenlo.com> wrote: > On Thu, Mar 24, 2016 at 8:27 PM, Christopher <ctubb...@apache.org> wrote: > > > It seems there's a general agreeme

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

> > intentionally don't want to modernize? > > On May 5, 2016 11:43 PM, "Christopher"<ctubb...@apache.org> wrote: > > > >> Another interesting point... didn't realize until actually doing it: > >> bumping to JDK8 *requires* a bump in the maj

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

is an acceptable solution... but it makes me unhappy :) ) On Thu, May 5, 2016 at 11:39 PM Josh Elser <josh.el...@gmail.com> wrote: > Thanks boss. I figured you'd have my back :) > On May 5, 2016 9:43 PM, "Christopher" <ctubb...@apache.org> wrote: > > > Already push

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

en on a call, so I haven't been able to push > that update. I'll get to it when I can, but perhaps someone has beaten > me to it already. > > Christopher wrote: > > Okay, so if we're okay treating the master branch as a 2.0 development > > branch, then I'm going to go ah

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

e that we are in agreement now and don't need a vote. > > I will create a 1.8 branch today (updating Jenkins appropriately) so we > can get master in a state that would be ready for the changes in 4177. > > Keith Turner wrote: > > On Tue, May 3, 2016 at 4:54 PM, Christopher<ctubb...@apa

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

ing Java 8 types/APIs was exactly the point -- > >> we got here from ACCUMULO-4177 which does exactly that. > >> > >> > >> Mike Drob wrote: > >> > >>> I agree with Shawn's implied statement -- why bother dropping Java 7 in > >>> any

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

> > > On Mon, May 2, 2016 at 6:42 PM, Christopher <ctubb...@apache.org> wrote: > > > I don't feel strongly about this, but I was kind of thinking that we'd > bump > > to Java 8 dependency (opportunistically) when we were ready to develop a > > 2.0 version.

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

I don't feel strongly about this, but I was kind of thinking that we'd bump to Java 8 dependency (opportunistically) when we were ready to develop a 2.0 version. But, I'm not opposed to doing it on the 1.8 branch. On Mon, May 2, 2016 at 2:50 PM William Slacum wrote: > So my

Re: Can someone review the change I made to the project RDF before I push to asf-site

Thanks for fixing that, Mike. I had thought that change might be a bit risky, as it's not clear to me the relationship between the content of category field in the DOAP and the people.apache.org website which no longer has categories at that location. It seems that the behavior is reliant on the

Re: On the future of our commons-vfs2 dynamic classloading implementation

> >> you feel is the best course of action to unblock us? > >> > >> dlmar...@comcast.net wrote: > >>> I feel your pain and am very frustrated by the lack of support from > the Commons team. I have brought up the subject multiple times[1,2,3] and &

Re: Accumulo not initializing

The warning about the ZooKeeper version is probably due to a trailing slash at the end of your environment variable for ZOOKEEPER_HOME. The max open files warning is regarding what is being discussed here:

Re: Our API compatibility history

That's cool. Thanks for having him update it with the API definition. I think I saw it before, and it looks much better now. On Fri, Apr 15, 2016, 19:47 Sean Busbey wrote: > Since this has now shown up in my Google alerts, I should stop dawdling on > pointing it out. > >

ASF GitHub Bot suggested change

Devs, Be advised I just created https://issues.apache.org/jira/browse/INFRA-11675 to propose changes to ASF GitHub Bot to make it more useful.

Re: GPG verification in GitHub tags

ome of the releases I made are now listed as "verified". > > Christopher wrote: > > Devs, > > > > I saw GitHub rolled out a new feature to verify GPG-signed commits and > tags > > in the UI [1]. If release managers upload their GPG public keys to their >

Re: LruBlockCache alternative

Thanks for the pointer! On Sun, Apr 3, 2016, 12:08 Benjamin Manes wrote: > Hi, > > I noticed that Accumulo's LruBlockCache [1] appears to be based on HBase's. > I currently have a patch being reviewed in HBASE-15560 [2] that replaces > the pseudo Segmented LRU with the

Re: Pros and Cons of moving SKVI to public API

rote: > > > On Thu, Mar 24, 2016 at 1:15 PM, Christopher <ctubb...@apache.org> > wrote: > > > > > We do have the opportunity to move to a new improved API, if somebody > > were > > > to put time into it. I guess that's true whether we put this in the >

Re: Pros and Cons of moving SKVI to public API

reason with how we have things > structured now which makes this infeasible/difficult, let's by all means > explore options (I didn't even realize that Yetus had their own audience > annotations). > > Christopher wrote: > > That's a good idea, at least for now, until we have a

Re: Pros and Cons of moving SKVI to public API

//yetus.apache.org/documentation/0.2.0/#yetus-audience-annotations > > That would allow us to mark specific classes, and even carve out particular > methods should we choose. > > On Thu, Mar 24, 2016 at 3:15 PM, Christopher <ctubb...@apache.org> wrote: > > > We do ha

Re: Pros and Cons of moving SKVI to public API

ame, it needlessly > diverges from the standard java Iterator calling standards), but it's a > strong, identifying feature we have. > > On Thu, Mar 24, 2016 at 2:50 PM, Christopher <ctubb...@apache.org> wrote: > > > Accumulators, > > > > What are the pros and cons that

Pros and Cons of moving SKVI to public API

Accumulators, What are the pros and cons that you can see for moving the SortedKeyValueIterator into the public API? Right now, I think there's still some need for improvement in the Iterator API, and many of the iterators may not be stable enough to really recommend people use without some

Re: git-based site and jekyll

is that linking directly to a section puts the section name underneath our top menu... that's kinda annoying, but not sure how to avoid it. Maybe make the menu auto-hide unless you're scrolled all the way to the top? On Tue, Mar 22, 2016 at 2:34 AM Christopher <ctubb...@apache.org> wrote: > I think

Re: git-based site and jekyll

ay to get this with Jekyll (or if it'd just be something we have to do > by hand). > > Christopher wrote: > > There's plenty of room for improvement to the new git/Jekyll site. For > > instance, we can start blogging there, so we have greater control over > the > &g

Re: git-based site and jekyll

osh.el...@gmail.com> wrote: > +1 > > Dylan Hutchison wrote: > > Sounds great Chris! > > > > On Fri, Mar 11, 2016 at 9:50 AM, Christopher<ctubb...@apache.org> > wrote: > > > >> So, if everybody's happy doing this, I'll go ahead and perform

Re: git-based site and jekyll

h our site to git using the accumulo.apache.org branch On Fri, Mar 11, 2016 at 11:46 AM Billie Rinaldi <billie.rina...@gmail.com> wrote: > Wow, that's looking great. Thanks, Christopher! > > Billie > > On Thu, Mar 10, 2016 at 10:38 PM, Christopher <ctubb...@apache.org>

Re: git-based site and jekyll

o/screenshots.html is weird with the > monitor screenshot (should be beneath the text?) > * Just noticed that Other and Documentation both have a link to the > papers/presentations. That might actually be how the site is now, just > realized it's duplicative. > > Thanks again for

Re: git-based site and jekyll

to switch from svn to git. On Thu, Mar 10, 2016 at 6:42 PM Christopher <ctubb...@apache.org> wrote: > I'm working on converting our current site contents over to jekyll at > https://github.com/ctubbsii/accumulo/tree/gh-pages > (view at http://ctubbsii.github.io/accumulo) > &g

Re: git-based site and jekyll

wrote: > Lazy consensus is fine. If there are no objections, I don't want to hold > things up. I feel like I've adequately expressed my concerns. Silence > can and should be treated as acknowledgement for this, IMO. > > Christopher wrote: > > Another reason we probably shouldn't wo

Re: git-based site and jekyll

mes about > for point #4 (or if we use the branch name gh-pages in point #1). > > Josh Elser wrote: > > The one concern I had was regarding automatic rendering of what would > > look like "the Apache Accumulo website" on Github (both apache/accumulo > > github account

git-based site and jekyll

I got some information back from INFRA about how the git-based sites work. It's just plain old static hosting of a git branch. So, whatever we'd put in a specified branch would show up directly on the site, no rendering or generation. This would completely bypass CMS and buildbot staging builds.

Re: 1.6 Javadoc missing classes

wrote: > Maybe the distributed tracing APIs? > > Christopher wrote: > > Sure, we can include that. Are there any other classes which would be > > good to have javadocs for which aren't public API? > > > > On Fri, Mar 4, 2016 at 4:03 PM Josh Elser <josh.el...@gmail.co

Re: [ATTN] Cleaning up extra refs in git

Any stats on what the repo size is after removing the refs and doing > something like `git gc`? > > On Fri, Mar 4, 2016 at 4:25 PM, Christopher <ctubb...@apache.org> wrote: > > > I was able to deleted 135 duplicate refs of the kind I described. Only > one > > resulted i

Re: [ATTN] Cleaning up extra refs in git

ive branch. Also note that the ACCUMULO-722 branch is not rooted on any other branches in our git repo. It was essentially just a sandbox in svn where Eric had been working. On Wed, Mar 2, 2016 at 6:14 PM Christopher <ctubb...@apache.org> wrote: > (tl;dr version: I'm going to clean up ref

Re: 1.6 Javadoc missing classes

t to discuss further. > > Christopher, looks like it might also be good to include iterator > javadocs despite not being in public API (interfaces, and o.a.a.c.i.user?). > > Original Message > Subject: 1.6 Javadoc missing classes > Date: Fri, 4 Mar 2016 15:59:26 -050

[ATTN] Cleaning up extra refs in git

(tl;dr version: I'm going to clean up refs/remotes/** in git, which contains duplicate history and messes with 'git clone --mirror'; these are refs which are neither branches nor tags and leftover from git-svn) So, when we switched from svn to git, there were a lot of leftover refs left in the

Re: [DRAFT][ANNOUNCE] Apache Accumulo 1.7.1

Sent and tweeted. On Fri, Feb 26, 2016 at 3:11 PM Billie Rinaldi <billie.rina...@gmail.com> wrote: > +1 > > On Fri, Feb 26, 2016 at 11:53 AM, Christopher <ctubb...@apache.org> wrote: > > > The Accumulo team is proud to announce the release of Accumulo version &

[ANNOUNCE] Apache Accumulo 1.7.1

The Accumulo team is proud to announce the release of Accumulo version 1.7.1! This release contains over 150 bugfixes and improvements over 1.7.0, and is backwards-compatible with 1.7.0. Existing users of 1.7.0 are encouraged to upgrade immediately. This version is now available in Maven

<    3   4   5   6   7   8   9   10   11   12   >