Re: [VOTE] "Manager" as new name for "master" service

+1 On 2020/08/03 13:53:40, Christopher wrote: > Based on the feedback on > https://github.com/apache/accumulo/issues/1638 , the following two > names have taken a clear lead in popularity for the new name for the > service currently known as "master": Manager and Coordinator. Of the > two,

Re: [LAZY][VOTE] change default branch to 'main'

+1 On 2020/08/03 11:58:31, Christopher wrote: > As a follow-up from our previous conversation on this issue, I have > already started a new branch named 'main' for my own future > contributions (that name because it appears to be the trending > alternative to 'master'), and for others who wish

Re: [LAZY][VOTE] change default branch to 'main'

+1 On 2020/08/03 11:58:31, Christopher wrote: > As a follow-up from our previous conversation on this issue, I have > already started a new branch named 'main' for my own future > contributions (that name because it appears to be the trending > alternative to 'master'), and for others who wish

Re: Issues building 1.9-snapshot and Hadoop 3.1.3

swap out Guava 27.0-jre with 27.0-android On Wed, Nov 20, 2019 at 9:51 PM Arvind Shyamsundar wrote: > > Hello! > Per this issue(https://github.com/apache/accumulo/issues/569) building 1.9.x > with Hadoop 3 support needs hadoop.profile=3. So I checked out current 1.9 > branch and built with

Re: [VOTE] Proposal to release version 1.10

things clearer for folks, expressly state what the voting rules are when announcing the vote. If you can't work out what they should be from the bylaws, then ask before calling a vote. On Tue, Nov 5, 2019 at 9:55 AM Sean Busbey wrote: > > Yeah I'm reading messages now. > > On Tue, Nov 5,

Re: [VOTE] Proposal to release version 1.10

ean's -1 vote is a veto [1] and we can not proceed down this path > > > unless it is withdrawn. I can only take the veto to mean there are > > > customers who would upgrade to Accumulo 1.10 but would not upgrade to Java > > > 1.8. Is there anything that would change your mi

Re: [VOTE] Proposal to release version 1.10

e a major version change. > > -Original Message- > From: Sean Busbey [mailto:bus...@cloudera.com.INVALID] > Sent: Friday, November 01, 2019 3:52 AM > To: dev@accumulo apache. org > Subject: Re: [VOTE] Proposal to release version 1.10 > > -1 no dropping supported ja

Re: [VOTE] Proposal to release version 1.10

-1 no dropping supported java versions in a minor release. if we want folks to move to java 8 then we should make it easier to upgrade to Accumulo 2.y On Thu, Oct 31, 2019 at 7:37 PM Ed Coleman wrote: > > As suggested in the LTS discussion ([LAZY][VOTE] A basic, but concrete, LTS > proposal),

Re: Commons Config in 1.9.3

reviewing my notes from the time period, it looks like I was attempting to make sure we didn't pull in a commons-collections version with open CVEs. have we already confirmed that no part of commons-configuration leaks into the public API for 2.0? On Mon, Apr 1, 2019 at 11:22 AM Mike Miller

Re: 2.0.0-alpha-2

Has anyone gotten to do a perf comparison to 1.9 yet? The time to do that would be during beta I guess? On Tue, Jan 15, 2019 at 5:18 PM Christopher wrote: > > I'm planning to prepare a 2.0.0-alpha-2-rc1 Thursday. So, merge your > stuff if you want me to include it then. > Depending on the

Re: Remove Google Analytics from project website

IIRC google analytics was one of the few ways Josh and I were able to look at the size of the "lurker population" for the project back when we tried to get a grasp on how the community was doing back in 2014. What will we do as an alternative for checking interest in the project expressed as

Re: commons-vfs2.jar 2.2 buggy

sounds like a good DISCUSS thread for 2.0? On Wed, Oct 24, 2018 at 1:43 PM Josh Elser wrote: > > It seems like commons-vfs2 is just a pile of crap. > > It's been known to have bugs for years and we've seen zero progress from > them on making them better. > > IMO, rip the whole damn thing out. > >

Re: [DISCUSS] 2.0.0-alpha?

On Tue, Oct 9, 2018 at 1:24 PM Keith Turner wrote: > > On Sat, Oct 6, 2018 at 1:36 PM Sean Busbey > wrote: > > > > yes alphas please. Do we want to talk about expectations on time > > between alpha releases? What kind of criteria for beta or GA? > > There are a

Re: [DISCUSS] 2.0.0-alpha?

And can we keep the master branch the one used for 2.0.0-* until 2.0.0 is ready for candidates for a GA release? On Sat, Oct 6, 2018 at 12:36 PM Sean Busbey wrote: > > yes alphas please. Do we want to talk about expectations on time > between alpha releases? What kind of criteria for b

Re: [DISCUSS] 2.0.0-alpha?

yes alphas please. Do we want to talk about expectations on time between alpha releases? What kind of criteria for beta or GA? a *lot* has changed in the 2.0 codebase. On Sat, Oct 6, 2018 at 11:45 AM Ed Coleman wrote: > > +1 > > In addition to the reasons stated by Christopher, I think that it

Re: apilyzer on branch 1.9

issing puzzle piece? If you have a branch, I could take a look. > On Fri, Sep 21, 2018 at 6:19 PM Sean Busbey wrote: > > > > I'm trying out a local change that I don't think changes the public API, > > but the apilyzer-maven-plugin is failing with a claim that the public API >

apilyzer on branch 1.9

I'm trying out a local change that I don't think changes the public API, but the apilyzer-maven-plugin is failing with a claim that the public API now contains non-public API parameters. The plugin is correct to flag the class it has a problem with, but I haven't changed the method it's

[DISCUSS] 1.9.2 release

heya folks, Our DRAFT board report for this month ( https://s.apache.org/AYwm ) mentions: > Another bug has been found in the WAL process and a 1.9.2 is in the works. I don't see anything on dev@accumulo around 1.9.2. Is someone already acting as RM? How do I figure out what, if any, issues

Re: [DISCUSS] Paper on Software licensing issues.

thanks for posting this Ed! On Tue, Jun 26, 2018 at 2:20 AM, Ed Coleman wrote: > I thought this may be of general interest to some - I'm not implying that > Accumulo has a specific issue, or that an action is required. > > > > On June 25th, the morning paper highlighted a study of open source

Re: [DISCUSS] Draft release timeline for 2.0.0

This makes me very worried. What's the expectation for how the release notes will come to include work being tracked via GitHub? Do we expect the release manager will go through things and update it as a part of make a release candidate? Should we be more proactive in getting release note

Re: [RESULT][VOTE] Apache Accumulo 1.9.0-rc1

On Wed, Apr 18, 2018 at 3:02 PM, Christopher wrote: > > > In response to Sean and Mike's comments, I copied the tarballs to the SVN > dist/dev area, along with their SHA512 sums, but no votes were changed as a > result. I saw no indication in the discussion that anybody

Re: [VOTE] Apache Accumulo 1.9.0-rc1

On 2018/04/16 01:26:54, Sean Busbey <bus...@apache.org> wrote: > > > On 2018/04/15 21:39:04, Christopher <ctubb...@apache.org> wrote: > > On Sun, Apr 15, 2018 at 10:11 AM Sean Busbey <bus...@apache.org> wrote: > > > > > > > However

Re: [VOTE] Apache Accumulo 1.9.0-rc1

Does "strongly against" in this case mean "-1" or still "-0" ? On 2018/04/15 17:24:33, Mike Drob wrote: > I am strongly against generating and publishing checksum information after > a vote because that ostensibly means it hasn't been verified and voted on. > > On Sun, Apr 15,

Re: [VOTE] Apache Accumulo 1.9.0-rc1

On 2018/04/15 21:39:04, Christopher <ctubb...@apache.org> wrote: > On Sun, Apr 15, 2018 at 10:11 AM Sean Busbey <bus...@apache.org> wrote: > > > -1 on the RC vote > > > > I agree that in the staged maven repository we should stick to SHOULD > > guida

Re: [VOTE] Apache Accumulo 1.9.0-rc1

his is going to be a new requirement for releases, it should be > documented with step by step instructions at https://accumulo.apache.org/ > contributor/making-release > > On Sun, Apr 15, 2018 at 10:12 AM, Sean Busbey <bus...@apache.org> wrote: > > > sorry, that should have b

Re: [VOTE] Apache Accumulo 1.9.0-rc1

sorry, that should have been "staged maven repository should stick to MUST guidance" On 2018/04/15 14:11:43, Sean Busbey <bus...@apache.org> wrote: > -1 on the RC vote > > I agree that in the staged maven repository we should stick to SHOULD > guidance until such

Re: [VOTE] Apache Accumulo 1.9.0-rc1

-1 on the RC vote I agree that in the staged maven repository we should stick to SHOULD guidance until such time that the maven tooling has a supported option to use correct checksums. (Have we verified that the relevant tooling at a minimum has a request in to add it?) However, I can't

Re: [DRAFT][ANNOUNCE] Apache Accumulo 1.7.4

A guide on upgrading to 1.8. Things that changed / broke that folks upgrading need to look out for, etc. On 2018/03/26 15:46:39, Christopher wrote: > What links? > > On Mon, Mar 26, 2018 at 8:26 AM Michael Wall wrote: > > > In your notice to upgrade,

Re: [DISCUSS] Switch to GitHub issues after trial

far. Does anyone have concerns about > > > moving these repos? > > > > > > https://github.com/apache/accumulo-docker > > > https://github.com/apache/accumulo-examples > > > https://github.com/apache/accumulo-testing > > > https://github.com/apache/accumul

[DISCUSS] status of Hadoop 3 for 1.9.0 release

hi folks! While reviewing things in prep for getting our master branch over to apache hadoop 3 only (see related discussion [1]), I noticed some wording on the last RC[2] for Hadoop 3.0.1: > Please note: > * HDFS-12990. Change default NameNode RPC port back to 8020. It makes > incompatible

Re: [DISCUSS] tracing framework updates

On 2018/02/27 16:39:02, Christopher wrote: > I didn't realize HTrace was struggling in incubation. Maybe some of us can > start participating? The project did start within Accumulo, after all. What > does it need? I also wouldn't want to go back to maintaining cloudtrace.

[DISCUSS] tracing framework updates

More things we should get ahead of for Accumulo 2.0.0: distributed tracing. Right now we have an awkward situation wrt HTrace support. We're using and shipping htrace 3.1. It works okay for our internal uses, afaict. Hadoop 2.6 ships and uses HTrace 3.0. I believe this does not work with 3.1.

[DISCUSS] dropping hadoop 2 support

Let's get the discussion started early on when we'll drop hadoop 2 support. As of ACCUMULO-4826 we are poised to have Hadoop 2 and Hadoop 3 supported in 1.y releases as of 1.9.0. That gives an upgrade path so that folks won't have to upgrade both Hadoop and Accumulo at the same time. How about

Re: [DISCUSS] Switch to GitHub issues after trial

On Fri, Feb 16, 2018 at 9:27 AM, Mike Walch wrote: > > > > Some of the concerns brought up would be answerable with a trial. How do > we > > do a release? What does aggregating issues fixed in a particular version > > look like? > > > > You can tag GH issues with a version but

Re: [DISCUSS] Proposed formatter change: 100 char lines

I'm opposed to requiring Java 8 to build on branches that we claim support running under Java 7. Historically relying on "compile for earlier target JDK" has just led to pain down the road when it inevitably doesn't work. Just make it a recommendation for contributions and have our precommit

Re: [DISCUSS] Moving away from Thrift

Similarly, see me on behalf of the HBase PMC prodding Hadoop to make more maintenance releases. Let's work out our messaging for "your downstreams ask you to please release" as well as our offer of help. On Fri, Nov 17, 2017 at 7:21 AM, Josh Elser wrote: > Did you offer to

Re: Updated Accumulo People page

Can we please remove the link to the github "contributors based on commits" feature? We expressly ask folks to opt-in to be listed on our people page. While we can't prevent third parties making publicly accessible indices of our git history we don't need to raise the visibility of them.

[DISCUSS] Hadoop 3 and our dependencies generally

Hi Folks! I think we need to start being more formal in planning for Hadoop 3. They're up to 3.0.0-alpha4 and are pushing towards API-locking betas[1]. What do folks think about starting to push on an Accumulo 2.0 release that only supports Hadoop 3? It would let us move faster, which we'll need

Re: [DISCUSS] Periodic table exports

This could also be useful for botched upgrades (should we change stuff in meta again). Don't we already default replication of the blocks for the meta tables to something very high? Aren't the exported-to-HDFS things just as subject to block corruption, or more-so if they use default replication?

Re: [DISCUSS] any blockers on current release lines?

te: >> >> Usually such discussions are in the context of an anticipated release. Are >> you planning to champion a release soon? I'd be in favor of a maintenance >> release or two. >> >> On Tue, Jun 13, 2017 at 4:57 PM Sean Busbey <bus...@cloudera.com> wrote: >>

Re: [DISCUSS] any blockers on current release lines?

> Link to issues, by release branch: > https://issues.apache.org/jira/projects/ACCUMULO?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page > > On Tue, Jun 13, 2017 at 3:09 PM Sean Busbey <bus...@apache.org> wrote: > >> Here's how we're doing on lag for r

[DISCUSS] any blockers on current release lines?

Here's how we're doing on lag for releases: * branch-1.7, last maintenance release March 25th 2017, 9 issues marked done, no blockers * branch-1.8, last maintenance release Feb 26th 2017, 14 issues marked done, no blockers * master, last minor release September 6th 2016, last major release May

Re: 1.6 to 1.7 performance regression

t; [2] https://accumulo.apache.org/blog/2016/11/02/durability-performance.html > > > Forwarded Message > Subject: Re: [DISCUSS] Question about 1.7 bugfix releases > Date: Tue, 6 Jun 2017 14:20:27 -0400 > From: Josh Elser <josh.el...@gmail.com> > To: dev@accumulo.apache

Re: [DISCUSS] Question about 1.7 bugfix releases

;> 1.7.x? >> >> On Tue, Jun 6, 2017 at 2:09 PM, Christopher <ctubb...@apache.org> wrote: >> >> > On Tue, Jun 6, 2017 at 12:39 PM Sean Busbey <bus...@cloudera.com> >> wrote: >> > >> > > Why do we consider 1.8.1 stable? >> > > >&g

Re: [DISCUSS] Question about 1.7 bugfix releases

On Tue, Jun 6, 2017 at 12:07 PM, Josh Elser <josh.el...@gmail.com> wrote: > On 6/6/17 12:39 PM, Sean Busbey wrote: >> >> For example, has anyone done perf comparisons between 1.7 and 1.8.z? >> >> When it came time for me to start telling folks that it was &q

Re: [DISCUSS] Question about 1.7 bugfix releases

will be and how long it will be maintained. > > My goal was not to imply 1.8 works and we should move to it, but rather > that whatever we define as stable and the primary location of bug fixes, > improvements, and security patches, is very clear to users. > > [1] https://docs.opensta

Re: [DISCUSS] Question about 1.7 bugfix releases

), and then into >> > (dev/master), we start at (dev-1). If it's a critical issue, we'll >> probably >> > want to start at (dev-2). If somebody contributes specifically because >> they >> > need/want something fixed in (dev-2), we encourage them to do so,

Re: [DISCUSS] Pull Request Guidelines

IIRC Josh did some work towards this end back at the start of 2016. I haven't checked on the current state of it in a long time though: https://builds.apache.org/job/PreCommit-ACCUMULO-Build/ On Mon, Jun 5, 2017 at 1:00 PM, Mike Drob wrote: > For what will be checked,

Re: [DISCUSS] Question about 1.7 bugfix releases

>> the 2.2 and 1.8 branches. >> >> If the 2.2 branch is identified as the next LTS branch, we could develop >> an easy upgrade script for enterprise users to go directly from 1.8 to 2.2 >> (skipping 2.0, 2.1). >> >> On Mon, Jun 5, 2017 at 3:12 PM Christ

Re: [DISCUSS] Question about 1.7 bugfix releases

On Mon, Jun 5, 2017 at 2:12 PM, Christopher <ctubb...@apache.org> wrote: > On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey <bus...@cloudera.com> wrote: > >> >> In my limited experience, when ASF projects don't reliably make >> maintenance releases, enterprise

Re: [DISCUSS] Question about 1.7 bugfix releases

On Mon, Jun 5, 2017 at 11:12 AM, Christopher <ctubb...@apache.org> wrote: > On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey <bus...@cloudera.com> wrote: > >> Many users in enterprise spaces have rules for upgrading to >> a new maintenance release that are different fr

Re: [DISCUSS] Question about 1.7 bugfix releases

Many users in enterprise spaces have rules for upgrading to a new maintenance release that are different from upgrading to a new minor release. Those rules presume a uniform understanding of the risks involved in each of those kinds of releases that I don't think exists, especially across open

Re: january 2017 board report draft

+1 On Mon, Jan 9, 2017 at 1:58 PM, Josh Elser wrote: > LGTM > > > Billie Rinaldi wrote: >> >> Hello all, >> >> The Apache Accumulo PMC has decided to start drafting its quarterly board >> reports on the dev list. Here is a draft of our report which is due on >> Wednesday.

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

I think a new permission would cover the concern about leaking meta-information. Even if only the administrative user could see the histogram (since they can see all data), that'd be a gain. -- Sean Busbey On Oct 11, 2016 16:33, "Mike Drob" <md...@mdrob.com> wrote: > I'v

Re: Testing on PR's

You can give Yetus a link to either a jira or a github PR and it'll work out what you mean most of the time. I think it'll only comment on the github PR if you start with that, but I haven't tried making use of the jira-to-github bridge in that direction. (I've only started with a jira in Patch

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 wrote: > I

Re: 1.8.0 RC3

yeah, any of mine are fine for bumping. They've been a problem for a while. On Fri, Aug 26, 2016 at 9:15 AM, Josh Elser wrote: > I would assume that ACCUMULO-4422 can be bumped as it's not a blocker, but I > should be able to run the tests I had asked Sean to do locally

Re: [VOTE] Plan for next release

On Tue, Aug 23, 2016 at 8:03 AM, Marc P. wrote: > I think there is value in commenting because after Reading the responses > last night I was swayed to -1. Perhaps others might be as well. > Sorry Marc, just for clarification are you changing your +1 vote to -1? I ask

Re: [VOTE] Plan for next release

-1 I would like to see the current feature set we've been building towards in 1.8 released with support for JDK7, both because that's what I see customers use and because that was the expectation as folks have contributed work towards this release in the little over 10 months since 1.7.0. we just

Re: [DISCUSS] Java 8

which is 99% similar to 1.8 >> with whatever else you'd like to do (in fact, I'd encourage anyone to >> step up and drive 2.0 to release). >> >> Sean Busbey wrote: >> > Why don't we just make the 1.8 branch 2.0 then? I really don't want to >> > drop su

Re: [DISCUSS] Java 8

t; >> 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 big deal. The good stuffs I was >> > hoping to

Re: [DISCUSS] Java 8

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 wrote: > I know we've talked about this before, but I kind of want to just use Java > 8 for

Re: Change in out-of-the-box log file naming after ACCUMULO-4328

This is definitely the kind of operational change that needs a release note. Are we tracking those on the JIRAs that introduce them, or somewhere else? On Mon, Aug 15, 2016 at 11:20 AM, Josh Elser wrote: > I noticed that the default log file names for Accumulo services has

Re: [VOTE] Accumulo 1.8.0-rc1

Just a heads up that I won't be able to test in that tight of a turn around. While I'm normally in favor of 72hr windows for maintenance releases, there's more I'd like to do to put a new minor version through paces and it'd be nice to have e.g. a week to get through things. Michael, can you

Re: Accumulo ITs on ASF Jenkins

. also we can probably speed things up by grouping the ITs up and running sets of them against a shared clusterdock topology[2]. [1]: https://github.com/cloudera/dist_test/blob/master/docs/grind.md [2]: https://github.com/cloudera/clusterdock On Wed, Aug 10, 2016 at 10:25 PM, Sean Busbey <

Re: Accumulo ITs on ASF Jenkins

to do the enumerating as a part of a launching job. Another would be to use a distributed test framework rather than Jenkins to do the parallelization. If no one else digs into these questions, I imagine I'll need to by the end of the year for other work related stuff. -- Sean Busbey On Aug 10

Re: [DISCUSS] Time for a 1.8.0 release?

On Thu, Aug 4, 2016 at 11:41 AM, Michael Wall wrote: > Sean, > > I'm interested. How do I get granted more permissions? I can't see the > configuration you used, but I can launch a new build. > > Mike > If you're interested, you subscribe to builds@ and infrastructure@ and

Re: [DISCUSS] Time for a 1.8.0 release?

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> wrote: > >> My understanding was that maintenance releases (aka double dot, e.g. >> 1.7.2) had relaxed criteria because we

Re: [DISCUSS] Time for a 1.8.0 release?

ink some of them could > become unit tests. And we really need them to run in less than 6 hours. > > Since only tickets for sporadicly failing ITs not part of the sunny profile > were left in Jira, I didn't want to hold up progress on the release. What > do others think? >

Re: [DISCUSS] Proposed binary packaging changes

I was hoping to have time last weekend to review the discussion on the PR, but didn't find it. Just so I have an idea while planning my week, 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,

Re: [DISCUSS] Proposal to remove docs/assemble profiles

+1 sounds great to me. On Thu, Jul 21, 2016 at 8:32 PM, Christopher wrote: > 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

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

We can also rely on nightly builds against jdk versions installed on ASF jenkins to catch incorrect api usage. On Wed, Jul 20, 2016 at 9:45 AM, Benson Margulies wrote: > On Wed, Jul 20, 2016 at 10:41 AM, Keith Turner wrote: >> On Wed, Jul 20, 2016 at

Re: [DISCUSS] Jenkins notifications to dev list?

What do we need to do to get an instance that we *would* be willing to rely on as the PMC? We could file an INFRA ticket for a VM we handle ourselves and then run a CI solution apart from the primary ASF jenkins infra. On Thu, Jul 14, 2016 at 3:14 PM, Christopher wrote: >

Re: [DISCUSS] Htrace4, Hadoop 2.7

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 version while incrementing our minor >> version number or our major version number? >

Re: [DISCUSS] Proposed binary packaging changes

On Fri, Jul 1, 2016 at 10:37 AM, Keith Turner <ke...@deenlo.com> wrote: > On Fri, Jul 1, 2016 at 10:44 AM, Sean Busbey <bus...@cloudera.com> wrote: > >> Targeting for 2.0, including updates in the README, and having mean for >> helping >> the downstream

Re: [DISCUSS] Proposed binary packaging changes

Targeting for 2.0, including updates in the README, and having mean for helping the downstream user find the appropriate licensing information makes me much more comfortable with this. I have to ask though, why not just do source only releases? Or source + publishing the binary jars to maven

Re: [VOTE] Accumulo 1.7.2-rc2

+1 * verified checksums and signatures * source artifact corresponds to referenced commit * source builds correctly with Oracle JDK 1.7.0_80 / Apache Maven 3.3.9 (including unit tests, not including ITs) * spot checked LICENSE and NOTICE On Fri, Jun 17, 2016 at 11:31 PM, Mike Drob

Re: [VOTE] Accumulo 1.7.2-rc1

On Fri, Jun 17, 2016 at 5:21 PM, Christopher wrote: > > > Sean, I noticed you committed the change you wanted to the LICENSE files, > in spite of my reference here indicating (more or less definitively) that > it wasn't actually necessary. The change itself doesn't bother me

Re: [VOTE] Accumulo 1.7.2-rc1

On Fri, Jun 17, 2016 at 2:53 PM, Sean Busbey <bus...@cloudera.com> wrote: > > > I'll file JIRAs for both issues, but the first one is still a blocker > for me, though I can understand why other folks might still vote +1. FYI, patches for both issues are now up on ACCUMULO-4346

Re: [VOTE] Accumulo 1.7.2-rc1

On Fri, Jun 17, 2016 at 2: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 >> core/src/main/java/org/apache/accumulo/core/bloomfilter"

Re: [VOTE] Accumulo 1.7.2-rc1

-1 good: * verified checksums and signatures * source artifact corresponds to referenced commit * source builds correctly with Oracle JDK 1.7.0_80 / Apache Maven 3.3.9 (including unit tests, not including ITs) bad: * LICENSE in source tarball references the "3 clause BSD" and "MIT" licenses

Apache Accumulo integrated with Presto

Bloomberg have a post about a connector they made to query Accumulo from Presto: http://www.bloomberg.com/company/announcements/open-source-at-bloomberg-reducing-application-development-time-via-presto-accumulo/ -- Sean Busbey

Re: [DISCUSS] Release 1.7.2

Do the folks assigned to those issues believe they'll be ready by e.g. Wednesday next week? Since it's been ~3 months I'd rather release the stuff we have if it'll take much longer than that. I'd be willing to commit to RM a 1.7.3 in a month if it makes folks more comfortable bumping things out.

Re: API changes analysis report

thanks for doing this analysis! On Tue, May 17, 2016 at 7:23 AM, Ponomarenko Andrey wrote: > Hello, > > The reports for the Accumulo library have been added to the API tracker > project: http://abi-laboratory.pro/java/tracker/timeline/accumulo/ > > One can look at

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

->7 upgrade different than a 7->8 upgrade? > On Mon, May 2, 2016 at 10:31 AM, Keith Turner <ke...@deenlo.com> wrote: > On Mon, May 2, 2016 at 1:54 AM, Sean Busbey <bus...@cloudera.com> wrote: > >> If we drop jdk7 support, I would strongly prefer a major version

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

If we drop jdk7 support, I would strongly prefer a major version bump. On Sun, May 1, 2016 at 1:43 PM, Josh Elser wrote: > Folks -- > > Let's come up with a plan for Java 8 support. Do we bump minJdk for > accumulo-1.8.0 to 8? Should we fork a branch for 1.8 and make master

Re: Our API compatibility history

d it looks much better now. > > On Fri, Apr 15, 2016, 19:47 Sean Busbey <bus...@cloudera.com> wrote: > >> Since this has now shown up in my Google alerts, I should stop dawdling on >> pointing it out. >> >> http://abi-laboratory.pro/java/tracker/timeline/accu

Our API compatibility history

since adopting semver! -- Sean Busbey

Re: LruBlockCache alternative

On Mon, Apr 4, 2016 at 9:45 AM, Keith Turner wrote: > On Mon, Apr 4, 2016 at 10:20 AM, Josh Elser wrote: > >> Cool, thanks for the poke, Ben! >> >> Last I checked, our version of the LRUBlockCache was nearly identical to >> what was in HBase 1.x. I would

Re: Pros and Cons of moving SKVI to public API

We could switch from a list of packages to annotations using the Apache Yetus Audience Annotations. http://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

Re: git-based site and jekyll

+1 sounds great! On Mon, Mar 7, 2016 at 5:09 PM, Christopher wrote: > 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

Re: Notes from a local co-working day

I am tentatively planning to attend ApacheCon Big Data (and maybe Core). On Thu, Mar 3, 2016 at 7:52 PM, Russ Weeks wrote: > Sounds very productive! Sucks to be 3 timezones away from the action :( > > Will any other Accumulo devs be attending ApacheCon this year? I'm

Re: [VOTE] Accumulo 1.7.1-rc2

+1 * verify signatures / checksums * verified LICENSE/NOTICE * source artifact corresponds to referenced commit * source builds correctly with Oracle JDK 1.7.0_75 / Apache Maven 3.2.2 (couple of transient timeouts in ITs) On Mon, Feb 22, 2016 at 3:41 PM, Christopher wrote:

Re: [DISCUSS] Pulling out the examples

I'd be +1 to making them an independent repo still controlled by the PMC. Whether they need to be a formal subproject or not I think could go either way. -- Sean Busbey On Feb 18, 2016 14:57, "Michael Wall" <mjw...@gmail.com> wrote: > Talking with Keith and Christopher to

Re: [VOTE] Accumulo 1.6.5-rc2

Can someone else do the Maven repo promotion, or is it tied to your ID? -- Sean Busbey On Feb 16, 2016 19:58, "Christopher" <ctubb...@apache.org> wrote: > I've pushed to dist, but then my internet went out, so I couldn't finish. > Typing this on my phone. Very frustrati

Re: [VOTE] Accumulo 1.6.5-rc2

+1 * all sigs / checksums pass * all license/notice check out * source tarball matches commit hash * source builds binary artifacts On Fri, Feb 12, 2016 at 5:19 PM, Christopher wrote: > Accumulo Developers, > > Please consider the following candidate for Accumulo 1.6.5.

Re: [VOTE] Accumulo 1.6.5-rc1

-1 bad: * Also ran into the copyright year thing and it matters to me enough to vote -1 (I understand that we're majority vote) * the PDF we're publishing contains no copyright statements or an indicator that the content is under the ASLv2 (ACCUMULO-4144) I don't think the PDF would be enough

[DISCUSS] Time for 1.7.1?

Hiya! How do folks feel about a 1.7.1 RC? We're past 8 months since 1.7.0 and up to 118 fixes that are in 1.7.1 and not the 1.6.1-1.6.4 releases. Is there anything that must get in before we have a release candidate? -- Sean

Re: Yetus Accumulo "Personality"

Excellent, thanks for working on this Josh! Is it worth us running our personality out of our code base rather than Yetus'? I'm not sure if we need the faster iteration speed or not. -Sean On Tue, Jan 5, 2016 at 12:00 AM, Josh Elser wrote: > FYI

Re: [DISCUSS] What to do about encryption at rest?

+1 on #2 if anyone wants to pick it back up later, we can always pull it back out of the git history. how would implementation work? I know it's not in the public API, but if there are folks relying on it we'd essentially be locking them out of upgrades. would we provide migration tools? On

  1   2   3   4   5   6   7   8   >