Re: Running Accumulo on a standard file system, without Hadoop

t I am > curious about both the single-node and distributed (via parallel file > system like Lustre) cases. > > Thanks, Dylan > -- Christopher

HipChat room

the current IRC integration, but that's probably because of the recent JIRA outages and the IRC notifications aren't back up yet. In any case, it's there if you want to use it. I'll lurk there occasionally, but will also stick to IRC #accumulo. -- Christopher

Re: Time for a 1.8.1?

rying to get a sense for where people > think we are. > > Mike > -- Christopher

Re: Blog post on Fedora

wrote: > https://github.com/apache/accumulo-website/pull/4 > > I've also ran into an issue that Christopher seems to have run into as > well: > > On a rebuild of the site locally, I get this error which breaks the > rebuild: > > Error: No repo name found. Specify u

Re: Blog post on Fedora

e much better ideas and > prevent the need to alter the root of HDFS, IMO. > -- Christopher

New git repos JIRA/GitHub integration

Devs, This is just a quick notice: I just filed https://issues.apache.org/jira/browse/INFRA-13069 due to some of our recently created repos being configured with the (annoying) defaults. Fixing this will help address things like the comments on

Re: [NOTICE] Moving source for accumulo website

Slight delay in the GitHub mirroring, due to https://issues.apache.org/jira/browse/INFRA-12955, but everything else is done. On Tue, Nov 22, 2016, 17:07 Christopher <ctubb...@apache.org> wrote: > As per https://issues.apache.org/jira/browse/ACCUMULO-4508 , > I've begun moving

[NOTICE] Moving source for accumulo website

As per https://issues.apache.org/jira/browse/ACCUMULO-4508 , I've begun moving the Accumulo website content over to a separate git repository: https://git-wip-us.apache.org/repos/asf/accumulo-website (history is preserved) Please commit website changes to the master branch here. The generated

Re: Please update your Jenkins job configs ASAP

Hi Gav, Thanks for the heads up. I didn't see any of our jobs using that label. However, I did make sure all ours changed to (Hadoop||ubuntu) and aborted a currently running build, to make sure that its next run used these nodes. On Thu, Nov 10, 2016 at 10:31 PM Gavin McDonald

My mistake (force push)

informed.) Christopher

Re: [DISCUSS] Moving Accumulo blog (was Re: [GitHub] accumulo pull request #170: ACCUMULO-4503 Added blog to project website)

Big +1 for me. This gives us a lot more control over publication of helpful topics, makes it easier to review/edit (via PR) additions, and makes it easier for users to find informative content. On Tue, Oct 25, 2016 at 12:31 PM Josh Elser wrote: > Just making sure that

Re: [DISCUSS] Would a visibility histogram on a table be harmful?

g more > about > >>> what you think. > >>> > >>> Marc P. wrote: > >>> > >>>> My point for discussing implementation outside of accumulo is because > I > >>>> think it does invalidate a core tenant > >>>> &g

Re: [DISCUSS] Would a visibility histogram on a table be harmful?

Keith, Russ, myself (and possible others) were discussing this at the hackathon after the Accumulo Summit, and I think our consensus were basically this: We need a generic pluggable mechanism for injecting arbitrary user counters into the RFiles. We can then use these counters in custom

Re: Missing docs for mapping arrays

Ugh, wrong list. Sorry. On Fri, Oct 7, 2016 at 5:32 PM Christopher <ctubb...@apache.org> wrote: > All- > > I noticed today, while reading the guide to configuring plugins[1], that > the information about mapping collections/lists explains how it is similar > to, and di

Missing docs for mapping arrays

All- I noticed today, while reading the guide to configuring plugins[1], that the information about mapping collections/lists explains how it is similar to, and different from, mapping arrays. However, there's no section on that page, or link to anywhere else, to explain how arrays themselves are

Re: Updates to Accumulo scripts for 2.0

I would strongly prefer we keep our scripts simple, to allow users to easily wrap them in cgroups, containers, systemd units, etc. Besides, cgroups don't even exist on all supported platforms. We should not be baking in cgroups management into the scripts directly. The easier we make Accumulo

[ANNOUNCE] Apache Accumulo 1.6.6

All- The Accumulo team is proud to announce the release of Accumulo version 1.6.6! This release contains changes from more than 40 issues, comprised of bug-fixes, performance improvements, build quality improvements, and more. This is a maintenance (patch) release. Users of any previous 1.6.x

Re: [VOTE] Accumulo 1.6.6-rc2

ep 21, 2016 at 8:35 AM, Michael Wall <mjw...@gmail.com> wrote: > > > Here is a draft, munged together from the release notes for 1.6.6 and the > > 1.7.2 announcement. I checked several mirrors and it seems the artifacts > > have propagated. Christopher, when you get in one of

Re: [VOTE] Accumulo 1.6.6-rc2

Okay, everything is done on the website. We still need to send out an announcement. Unfortunately, I have a few other tasks to take care of, so if somebody else wants to volunteer to do that, I'd very much appreciate it. On Tue, Sep 20, 2016 at 1:29 PM Christopher <ctubb...@apache.org>

Re: [VOTE] Accumulo 1.6.6-rc2

Still working on the release notes and updating the site. Everything else is done, I think. On Sun, Sep 18, 2016 at 8:32 PM Christopher <ctubb...@apache.org> wrote: > This vote passes with +3 (not including Mike's late +1). I'll push things > out to dist tonight and try to put t

Re: [VOTE] Accumulo 1.6.6-rc2

> > data, verify, and view monitor > > * was able to build Fluo against the artifacts in staging repo > > > > On Thu, Sep 15, 2016 at 4:54 PM, Christopher <ctubb...@apache.org> > wrote: > > > Accumulo Developers, &

Re: [VOTE] Accumulo 1.6.6-rc2

and saw no changes. I see two new properties... not technically public API... but surprised to see them (and should be in release notes): tserver.walog.max.age (to fix a bug: ACCUMULO-4004) gc.wal.dead.server.wait (to fix a bug: ACCUMULO-4157) On Fri, Sep 16, 2016 at 12:13 AM Christopher <ct

Re: [VOTE] Accumulo 1.6.6-rc2

fied repo contains 2073a07460603ebdb2caec3f6b7b863293cbfadb > * `mvn package` && `mvn package -Dhadoop.profile=1` both pass > * xsums/sigs OK > > - Josh > > Christopher wrote: > > Accumulo Developers, > > > > Please consider

[VOTE] Accumulo 1.6.6-rc2

Accumulo Developers, Please consider the following candidate for Accumulo 1.6.6. Git Commit: 2073a07460603ebdb2caec3f6b7b863293cbfadb Branch: 1.6.6-rc2 If this vote passes, a gpg-signed tag will be created using: git tag -f -m 'Apache Accumulo 1.6.6' -s rel/1.6.6 \

Re: [VOTE] Accumulo 1.6.6-rc1

Ran pseudo-dist install with build from src > > * Ran pseudo-dist instal with bin > > * Checked L, look to be as expected > > > > - Josh > > > > Christopher wrote: > >> Accumulo Developers, > >> > >> Please consider the follow

Re: [VOTE] Accumulo 1.6.6-rc1

with src-tarball * jar artifacts match what's in src-tarball * verified jars have corresponding source/javadoc jars On Tue, Sep 13, 2016 at 7:30 PM Josh Elser <josh.el...@gmail.com> wrote: > Christopher wrote: > > On Tue, Sep 13, 2016 at 1:54 PM Josh Elser<els...@apache.org> wrote

Re: [VOTE] Accumulo 1.6.6-rc1

On Tue, Sep 13, 2016 at 1:54 PM Josh Elser wrote: > Looks like the branch is actually "1.6.6-rc0" btw. (SHA1 does match > which is the important part) > I renamed the branch just before I sent this email.

[VOTE] Accumulo 1.6.6-rc1

Accumulo Developers, Please consider the following candidate for Accumulo 1.6.6. Git Commit: ac169c7167a9c0ca94f9c8d587974e8acbe4c382 Branch: 1.6.6-rc1 If this vote passes, a gpg-signed tag will be created using: git tag -f -m 'Apache Accumulo 1.6.6' -s rel/1.6.6 \

Preview 1.6.6-rc0

I just staged a release candidate for testing 1.6.6: https://repository.apache.org/content/repositories/orgapacheaccumulo-1058/ Branch: 1.6.6-rc0 Commit: ac169c7167a9c0ca94f9c8d587974e8acbe4c382 This isn't a vote... it's just to give time for preview testing before I start the vote. I'll turn

Re: [DISCUSS] Release plan 1.6.6

I'm going to try to create a release candidate soon (today), so people can begin testing on an essentially frozen branch. If there are no surprises or changes, I'll start the vote next Monday from those same artifacts. On Fri, Sep 9, 2016 at 1:41 PM Christopher <ctubb...@apache.org>

Re: [DISCUSS] Release plan 1.6.6

to go for 1.6.6. > > Christopher wrote: > > Okay, so now that 1.8.0 is wrapping up, I'd like to push out a release of > > 1.6.6, and plan to cease active development on that branch. > > > > This will allow us to focus our development and bugfixes on the latest > > rel

Re: [DISCUSS] Official release dates / DOAP out-of-date

ComDev list). On Wed, Sep 7, 2016 at 11:06 AM Christopher <ctubb...@apache.org> wrote: > Okay, SVN dist date is easy enough to check, based on SVN commit > timestamps. I'll converge on those. I'm not so concerned about precision as > I am about consistency, especially to inf

Re: [DISCUSS] Release plan 1.6.6

On Tue, Sep 6, 2016 at 9:08 PM Josh Elser <josh.el...@gmail.com> wrote: > Christopher wrote: > > Okay, so now that 1.8.0 is wrapping up, I'd like to push out a release of > > 1.6.6, and plan to cease active development on that branch. > > +1 > > > This wi

Re: [DISCUSS] Official release dates / DOAP out-of-date

; I agree with Billie that the technically-correct-ASF-policy-date is > the SVN dist date. Similar to Josh I don't think this is a place where > we need a lot of precision and anything within a week or two is good > enough. > > On Tue, Sep 6, 2016 at 6:36 PM, Christopher <ctubb.

[DISCUSS] Release plan 1.6.6

Okay, so now that 1.8.0 is wrapping up, I'd like to push out a release of 1.6.6, and plan to cease active development on that branch. This will allow us to focus our development and bugfixes on the latest releases, while closing out the 1.6 line with a rollup of the bugfixes we've worked so far.

[DISCUSS] Official release dates / DOAP out-of-date

I noticed that there were a few missing releases in our DOAP file, and I also noticed lots of discrepancies between what's in JIRA as the release date, when the tag was created, when the announcement was made (and on which list), what the date was in reporter.apache.org, and what the date was in

Re: [VOTE] Accumulo 1.8.0-rc4

+1 * Manually inspected the diff and all looks as expected * Verified SIGs and hashes * Verified commit and branch match contents of src tarball * Verified jars in staging repo match what's in bin tarball * All ITs (periodic timeouts, as usual; work on retry) successfully (have another run

Re: ACCUMULO-4423 in 1.8.0 (Re: [VOTE] Accumulo 1.8.0-rc3)

t say that I didn't expect to have this put in 1.8.0 when I > was working on it. Not that it changes much anything, just thought I > would mention that my intentions were specifically to _not_ hold up 1.8.0. > > Christopher wrote: > > +0 > > > > Verified a

Re: [VOTE] Accumulo 1.8.0-rc3

; > I really think this should just go out... > > Michael Wall wrote: > > This vote fails with > > > > two +1s > > one +0s > > > > There was also a +0 and +1 that came in after the vote expired. > > > > Christopher has identified

Re: [VOTE] Accumulo 1.8.0-rc3

.0. If this vote passes, > I'll > resolve all concerns about the release notes before finalizing the release. > > Mike > > On Thu, Sep 1, 2016 at 1:30 PM, Christopher <ctubb...@apache.org> wrote: > > > I've done some initial checks and things basically look good.

Re: [VOTE] Accumulo 1.8.0-rc3

I've done some initial checks and things basically look good. However, there are still a few tests failing due to timeouts and related platform-variant expectations. I also noticed that because of ACCUMULO-3929, many tests have been overlooked entirely (at least by me) for the entire development

Re: JUnit categories in surefire/failsafe

On Wed, Aug 31, 2016 at 4:23 AM Tibor Digana <tibordig...@apache.org> wrote: > Hi Christopher, > > Some offtopic. I will answer your email but first I have a question for you > and Accumulo project. > I visited Accumulo cca one week ago. Why the build [1] hangs on IT tes

Re: Lots of "Connection reset by peer"

inished with the work in a thread but kept opening > thrift connections since it would be 'time sliced' for io. In that case I > opened too many sockets ( fds )...maybe hitting max open files because a > transport isn't being returned in the middle of a work unit ? > > On Tue, Aug 30, 2016, 6:12

Lots of "Connection reset by peer"

Thrift is not happy on some replication ITs I've run lately. I had one test timeout after 40 minutes... and it never finished. The symptom is lots of client side messages about failure to open transport, and the server side messages were (and both were occurring a *lot*, indicating indefinite

Re: 1.8.0 RC3

Elser <josh.el...@gmail.com> wrote: > We're ready to go now, Mike. > > Michael Wall wrote: > > I was going to make another RC for 1.8.0, but we have open 4 tickets. > See > > 1.8.0 > > <https://issues.apache.org/jira/browse/ACCUMULO/fixforversion/12329879>

Re: 1.8.0 RC3

JIRA. I can try to find some time this weekend to dig in. > > Christopher wrote: > > I'm currently bisecting to figure out what's going on with ACCUMULO-4425. > > The test isn't very well documented, and there's no server-side problems, > > so I'm trying to infer from co

Re: 1.8.0 RC3

gt; > there too. > > > > > > Michael Wall wrote: > >> > >> I was going to make another RC for 1.8.0, but we have open 4 tickets. > See > >> 1.8.0 > >> <https://issues.apache.org/jira/browse/ACCUMULO/fixforversion/12329879> > >> >

[RESULT][VOTE] Plan for next release

This vote fails with -1. I know disagreement can't be painful, so I appreciate everyone's participation. Thank you. The plan to release a 1.8 branch which supports Java 7 will proceed. Binding Votes: +4 (edcoleman, brianloss, mjwall, dlmarion) -5 (ctubbsii, elserj, dhutchis, busbey, drew)

Re: [VOTE] Plan for next release

Elser <josh.el...@gmail.com> wrote: > > > Please just let people vote, Christopher. We don't need to have the > > continued chatter on every vote being cast... > > > > Christopher wrote: > > > That was previously proposed and discussed, and the argument agai

JIRA cleanup

This is just a heads-up that I'm going to drop the 1.9.0 fixVersion in JIRA, and bump all the existing issues slated for it to 2.0.0. Depending on the outcome of the current [VOTE] thread, it seems there's at least some consensus that the next major/minor version we'll be working towards after the

Re: [VOTE] Plan for next release

That was previously proposed and discussed, and the argument against it was that it would either increase our support burden or we'd have to prematurely EOL 1.7. On Tue, Aug 23, 2016, 10:51 ivan bella wrote: > If 1.8 and 2.0 are so close, then just release both back to

Re: [VOTE] Plan for next release

; > Sent: Tuesday, August 23, 2016 8:15:01 AM > > Subject: Re: [VOTE] Plan for next release > > > > If we really need to keep arguing about this, then this vote is > premature. > > Responses inline. > > > > On Aug 23, 2016 00:18, "Christopher" <

Re: [VOTE] Plan for next release

m>> wrote: > >> > >> (sorry posting from phone) > >> > >> I missed the run jdk7 artifacts on jdk8 comment: I am not concerned > >> about this case (Oracle worries about it for me). I am worried about > >> jdk8 features being in

Re: [VOTE] Plan for next release

On Mon, Aug 22, 2016 at 5:38 PM Michael Wall wrote: > The only negative I can see is that the work we did for the 1.8 RCs is > wasted. The advantages listed above far outweigh that for me. > Not entirely wasted. The testing was informative and produced a few issues to

Re: [VOTE] Plan for next release

My vote is +1, because I don't think we *need* an extra release line named 1.8, when a 2.0 release from master will suffice, and in particular because of the backwards-compatibilities it will have with 1.7/1.6. On Mon, Aug 22, 2016 at 5:21 PM Christopher <ctubb...@apache.org> wrote: >

[VOTE] Plan for next release

After our lengthy (sorry for that) discussions about Java 8, 1.8.0, and 2.0.0, I wanted to bring us to a vote, just so we can have a concrete plan of action, without any ambiguity or uncertainty. A vote is the best option available for resolving differences of opinion about our upcoming release

Re: BatchWriter Auth/Audit Question

to avoid concurrent execution of the code which does that check without additional verification of correctness. On Fri, Aug 19, 2016 at 6:10 PM Mike Drob <md...@apache.org> wrote: > I got a bit confused here, so I hopped on IRC and tried to reason this out > with Christopher. > >

Re: BatchWriter Auth/Audit Question

Sorry, I meant, that it wouldn't be executed in the write path if you switch the order. The two credentials should always be the same in that case. On Fri, Aug 19, 2016 at 4:37 PM Christopher <ctubb...@apache.org> wrote: > Correct. That code is not executed in the write path. It sh

Re: BatchWriter Auth/Audit Question

k that code is ever executed during > the write path. > > > Mike > > > > On Fri, Aug 19, 2016 at 2:42 PM, Christopher <ctubb...@apache.org> wrote: > > > If you note the comment in the parent class, the implementation of > > canAskAboutUser is relying on the au

Re: [DISCUSS] Java 8

that is there were a result of that commit. On Fri, Aug 19, 2016 at 1:08 PM Christopher <ctubb...@apache.org> wrote: > Re-reading the old thread, I'm reminded that we actually can't bump > without either disabling the modernizer plugin or making some minimal > breaking changes in mock (w

Re: BatchWriter Auth/Audit Question

If you note the comment in the parent class, the implementation of canAskAboutUser is relying on the authentication being done in the call to canPerformSystemActions. If you reverse the order here, you lose that authentication check, and the action will be allowed simply if the user is equal to

Re: [DISCUSS] Java 8

be a name-only change, unless we disable modernizer. On Thu, Aug 18, 2016 at 7:30 PM Christopher <ctubb...@apache.org> wrote: > Yes, and we ended up going with the "defer" option instead of the two > subsequent releases option. Given my concerns about spreading ourselves t

Re: [VOTE] Accumulo 1.8.0-rc2

, but I'm not 100% certain. I've asked the question on the maven users list to see if there are better suggestions: https://lists.apache.org/thread.html/fe89f6d5d29808973d2f948e6fcdaab8a83f8820b92e6c182c73b4e8@%3Cusers.maven.apache.org%3E On Tue, Aug 16, 2016 at 4:58 PM Christopher <ctubb...@apache.

Re: [DISCUSS] Java 8

t; > Found it: > http://mail-archives.apache.org/mod_mbox/accumulo-dev/201605.mbox/ > <2113920695.26610898.1462308522327.javamail.zim...@comcast.net> > > On Aug 18, 2016 7:13 PM, "Christopher" <ctubb...@apache.org> wrote: > > > Oh, master is in a terrible state (te

Re: [DISCUSS] Java 8

th Java 8 as the minimum version? What's the > blocker on a release from master now? > > On Thu, Aug 18, 2016 at 5:46 PM, Christopher <ctubb...@apache.org> wrote: > > We need to make sure this release works with Java 8 anyway... but this > > change would tighten things up a bit

Re: [DISCUSS] Java 8

ses; it's super disruptive. > > > > On Thu, Aug 18, 2016 at 4:01 PM, Christopher<ctubb...@apache.org> > wrote: > >> I know we've talked about this before, but I kind of want to just use > Java > >> 8 for Accumulo 1.8. It'd help clean up some things in the build

Re: [DISCUSS] Java 8

;bus...@cloudera.com> wrote: > > > Why don't we just make the 1.8 branch 2.0 then? I really don't want to > > drop support for JDKs on non-major releases; it's super disruptive. > > > > On Thu, Aug 18, 2016 at 4:01 PM, Christopher <ctubb...@apache.org> > wrot

Re: [DISCUSS] Java 8

ave to redo all the > testing, which is fine too. > > On Thu, Aug 18, 2016 at 5:55 PM, Christopher <ctubb...@apache.org> wrote: > > > That's fine with me. I think people might expect a bigger jump with a > major > > version change like that, but it's not a b

Re: [DISCUSS] Java 8

don't we just make the 1.8 branch 2.0 then? I really don't want to > drop support for JDKs on non-major releases; it's super disruptive. > > On Thu, Aug 18, 2016 at 4:01 PM, Christopher <ctubb...@apache.org> wrote: > > I know we've talked about this before, but I kind of

[DISCUSS] Java 8

I know we've talked about this before, but I kind of want to just use Java 8 for Accumulo 1.8. It'd help clean up some things in the build (can make use of newer versions of build plugins, and make it easier for new development against the latest release). I just don't know how reasonable it is

Re: bulk load architecture

Bumping this thread up, because I'm also curious if anybody has any thoughts on Adam's questions. On Mon, Aug 15, 2016 at 1:49 PM Adam Fuchs wrote: > I've been looking through the bulk load code lately related to some > performance issues a customer of ours is experiencing,

Re: Re: Accumulo 1.7 InputFormat Iterator Question

I'm not sure it's really necessary to add the ability to clear. The way I see it, you create the configuration, then execute, create a new configuration, then execute, etc. I'm not sure what the use case is for clearing if you didn't want it there, why did you add it only to remove it? But it

Re: [VOTE] Accumulo 1.8.0-rc2

-1 There seems to be a lot of new content in this release which shouldn't be there. There now exists an accumulo-test-1.8.0-tests.jar (test's test-jar), and the accumulo-test-1.8.0.jar now contains a bunch of new content not in the org/apache/accumulo/test/* resource namespace: conf/ unit/

slf4j changes

I'm going to try to start working on cleaning up some of our log initialization stuffs, in order to help make it easier for users to use a different log implementation than log4j. This will involve setting log4j.configuration system property in our scripts to point to the appropriate

Re: [GitHub] accumulo issue #137: ACCUMULO-4406: Add instance number to .out and .err fil...

Wish my GH feature requests are implemented so quickly... barely hours. On Mon, Aug 15, 2016 at 4:13 PM Josh Elser wrote: > Creepy... > https://github.com/blog/2224-change-the-base-branch-of-a-pull-request > > dlmarion wrote: > > Github user dlmarion commented on the

Re: Custom Java SecurityManager permissions

system to our code, but they don't look like they are offering anything in the current implementation to actually improve the security. On Thu, Aug 11, 2016 at 9:46 PM Christopher <ctubb...@apache.org> wrote: > I found 7 references in our code (master branch, probably same

Re: Snappy as default table.file.compress.type?

t understanding this would be good. > > Is there a nonnative snappy impl? > > On Aug 13, 2016 11:19 PM, "Christopher" <ctubb...@apache.org> wrote: > > > Native libraries for snappy are also not typically installed by default > on > > Linux distros.

Re: Snappy as default table.file.compress.type?

ard across all > installations > > I've worked with for years. > > > > Asking because I am no oracle on the matter. I could just be ignorant of > > some issue, but, given my current understanding, there is no downside for > > the average case. > > > > Christophe

Re: Snappy as default table.file.compress.type?

library availability of snappy? GZ is pretty ubiquitous. On Sat, Aug 13, 2016 at 10:59 PM Josh Elser <josh.el...@gmail.com> wrote: > Uhh, besides what I already mentioned? (close in compressed size but > "much" faster) > > Christopher wrote: > >

Re: Snappy as default table.file.compress.type?

What's the motivation for changing it? On Sat, Aug 13, 2016 at 10:47 PM Josh Elser wrote: > Any reason we don't want to do this? Last rule-of-thumb I heard was that > snappy is often close enough in compression to GZ but quite a bit faster > (I don't remember exactly how

Re: [VOTE] Accumulo 1.8.0-rc1

Okay. On Sat, Aug 13, 2016 at 9:48 PM Josh Elser <josh.el...@gmail.com> wrote: > Already taken care of :) > > Christopher wrote: > > -1 vote from me. > > Ugh. Thanks for finding this Josh. I'll take care of it. > > > > On Sat, Aug 13, 2016 at 8:54 PM

Re: [VOTE] Accumulo 1.8.0-rc1

-1 vote from me. Ugh. Thanks for finding this Josh. I'll take care of it. On Sat, Aug 13, 2016 at 8:54 PM Josh Elser wrote: > Both. No matter if you provide an instance name or don't, it just > reprompts you. > > Filed ACCUMULO-4401 to fix, caused by removing "unnecessary

Re: [VOTE] Accumulo 1.8.0-rc1

On Fri, Aug 12, 2016 at 12:48 PM Josh Elser wrote: > IMO, you don't need to cancel this RC if there is agreement to extend > the timeframe and there isn't anything found that needs to be fixed > (avoiding referencing -1's because release votes are majority -- > Accumulo is

Re: [DISCUSS] Time for a 1.8.0 release?

> These are moved back to release 1.8.0 and are blockers. > > On Fri, Aug 5, 2016 at 10:29 AM, Josh Elser <josh.el...@gmail.com> wrote: > > > Sean Busbey wrote: > > > >> On Wed, Aug 3, 2016 at 5:17 PM, Christopher<ctubb...@apache.org> > wrote: &

Re: [VOTE] Apache Fluo Parent POM 1 (rc3) and Build Resources 1.0.0 (rc1)

To clarify... I sent this to the wrong list. On Thu, Aug 4, 2016 at 4:48 PM Christopher <ctubb...@apache.org> wrote: > Aww, crap. I knew I was going to screw something up... sorry all, please > ignore this vote. >

Re: [VOTE] Apache Fluo Parent POM 1 (rc3) and Build Resources 1.0.0 (rc1)

Aww, crap. I knew I was going to screw something up... sorry all, please ignore this vote.

[VOTE] Apache Fluo Parent POM 1 (rc3) and Build Resources 1.0.0 (rc1)

Fluo Developers, I'm combining these two votes, because they are a bit interdependent, and both are small. Please consider the following candidates for Fluo Parent POM 1-incubating and Fluo Build Resources 1.0.0-incubating. Git Commits/branches: 02d4ea2332598a94285985ee8a1c8e92a42b4770

Re: [DISCUSS] Time for a 1.8.0 release?

ew build. > > Mike > > On Thu, Aug 4, 2016 at 12:24 PM, Sean Busbey <bus...@cloudera.com> wrote: > > > On Wed, Aug 3, 2016 at 5:17 PM, Christopher <ctubb...@apache.org> wrote: > > > On Wed, Aug 3, 2016 at 5:47 PM Sean Busbey <bus...@cloudera.com> > wr

Re: [DISCUSS] Time for a 1.8.0 release?

On Wed, Aug 3, 2016 at 5:47 PM Sean Busbey wrote: > My understanding was that maintenance releases (aka double dot, e.g. > 1.7.2) had relaxed criteria because we expected the scope of changes > in them to be more limited. Even so, the release notes for 1.7.2, > 1.7.1, and

Re: [DISCUSS] Time for a 1.8.0 release?

minor to make it in. On Wed, Aug 3, 2016 at 5:11 PM Michael Wall <mjw...@gmail.com> wrote: > Good points Christopher. > > Here are the patch available tickets. > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20ACCUMULO%20AND%20status%20%3D%20%22Patch%20Available%22%20

Re: [DISCUSS] Time for a 1.8.0 release?

tomorrow. I'll start with a RC0 to work out the > process then make an RC1 if that goes smoothly. > > On Fri, May 27, 2016 at 5:13 PM, Keith Turner <ke...@deenlo.com> wrote: > > > On Thu, May 26, 2016 at 8:57 PM, Michael Wall <mjw...@gmail.com> wrote: > > > > &

Re: [DISCUSS] Proposed binary packaging changes

how big of a hurry are > you to get this in Christopher? Would giving me next weekend be too > long? I'm happy to only review after the fact if it is. > > On Thu, Jul 21, 2016 at 7:39 PM, Christopher <ctubb...@apache.org> wrote: > > Here's the PR I was thinking: > https://github.c

[DISCUSS] Remove directory assembly

Hi all, Awhile back, when I was working on moving all our build artifacts to the target directory during a maven build, I created a directory assembly, which looked just like an extracted binary tarball, in the aseemble/target directory (or another location, if you overrode the DEV_ACCUMULO_HOME

Unused variable unassignedCount?

Hey Shawn, I noticed that in SuspendedTabletsIT, there is an unused variable called unassignedCount. Was it intended to make use of this and this is revealing a bug of omission, or is it vestigial and safe to delete? Thanks.

[DISCUSS] Proposal to remove docs/assemble profiles

We have some build profiles which aren't active by default, and I'm not sure they're needed any more. We can simplify builds a bit by simply always executing these tasks. The ones I'm thinking of in particular are: -P docs -P assemble Respectively, these build the asciidocs, and the binary

Re: [DISCUSS] Proposed binary packaging changes

Here's the PR I was thinking: https://github.com/apache/accumulo/pull/131 This gives us something concrete to discuss. On Mon, Jul 18, 2016 at 4:36 PM Christopher <ctubb...@apache.org> wrote: > On Mon, Jul 18, 2016 at 4:35 PM Josh Elser <josh.el...@gmail.com> wrote: > >>

Re: [OT] Can no longer obtain JDK6/JDK7 tarballs

On Wed, Jul 20, 2016 at 9:13 AM Keith Turner wrote: > Is running jenkins on Centos 6 an option? Then maybe Centos6 has OpenJDK6 > and 7?? And can download Sun JDK8 for Centos 6. > > Jenkins is running on CentOS 7, which ships with support for OpenJDK 6, 7, and 8. I still have

[OT] Can no longer obtain JDK6/JDK7 tarballs

I know we've discussed moving to JDK8 before, and we've moved the master branch, which is expected to be 2.0.0. However, I'm trying to get the tarball for JDK7, so I can do development on older Accumulo branches while guaranteeing I don't do anything which will only work in JDK8. Unfortunately,

Re: [DISCUSS] Proposed binary packaging changes

On Mon, Jul 18, 2016 at 4:35 PM Josh Elser <josh.el...@gmail.com> wrote: > > > Christopher wrote: > >> I've had quite the foray into ASF release policies over the past two > >> > days which brings me back to this. > >> > > >> > I

Re: [DISCUSS] Proposed binary packaging changes

On Mon, Jul 18, 2016 at 2:24 PM Josh Elser <josh.el...@gmail.com> wrote: > Christopher wrote: > > On Thu, Jun 30, 2016 at 5:43 PM Christopher<ctubb...@apache.org> wrote: > > > >> Hi all, > >> > >> I'd like to bring to your attention &g

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