+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, "Mana
+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 t
+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 t
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 -Dha
2) To make 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.
>
> > > However Sean'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 anyt
dencies - and would not require 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
-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), I'm
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 wrot
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 quality
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 we
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.
>
>
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
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
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 al
> the missing 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
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 talking
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
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 lic
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 detail
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 other than
> myself examin
On 2018/04/16 01:26:54, Sean Busbey wrote:
>
>
> On 2018/04/15 21:39:04, Christopher wrote:
> > On Sun, Apr 15, 2018 at 10:11 AM Sean Busbey wrote:
> >
> >
> > > However, I can't verify that the source artifact or any other artifacts
>
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, 2018 at 12:35 AM,
On 2018/04/15 21:39:04, Christopher wrote:
> On Sun, Apr 15, 2018 at 10:11 AM Sean Busbey wrote:
>
> > -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 suppo
s 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 wrote:
>
> > sorry, that should have been "staged maven
sorry, that should have been "staged maven repository should stick to MUST
guidance"
On 2018/04/15 14:11:43, Sean Busbey wrote:
> -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 t
-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 verify
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, it would be nice to provide some links.
>
Hi Folks!
If anyone has a few minutes to verify some changes, I could use a review
related to Accumulo support over on the YCSB project.
[accumulo1.6, scripts] deprecate Accumulo 1.6 client, since Accumulo 1.6 is
EOM. #1114
https://github.com/brianfrankcooper/YCSB/pull/1114
In the YCSB commun
e repos?
> > >
> > > https://github.com/apache/accumulo-docker
> > > https://github.com/apache/accumulo-examples
> > > https://github.com/apache/accumulo-testing
> > > https://github.com/apache/accumulo-website
> > > https://github.com/apache/accumulo-wik
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 chan
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.
>
I suspect it's too
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.
H
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
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 I think it's best t
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
check
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 make the release? See
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.
Addition
Hadoop 3 for Accumulo 2. If we do this then
> Accumulo 2 can not release until after Hadoop 3 does. Any idea when
> Hadoop 3 will release?
>
> On Thu, Aug 3, 2017 at 10:08 AM, Sean Busbey wrote:
> > Hi Folks!
> >
> > I think we need to start being more formal in pla
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
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?
gt;> 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 wrote:
>>
>>> Right, I beli
s, 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 wrote:
>
>> Here's how we're doing on lag for releases:
>>
>> * branch-1.
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 2
tps://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
> To: dev@accumulo.apache.org
>
> On 6/6/17 2:
t; Mike Drob
>> Sent: Tuesday, June 06, 2017 3:14 PM
>> To: Accumulo Dev List
>> Subject: Re: [DISCUSS] Question about 1.7 bugfix releases
>>
>> Are there potentially destabilizing new features in 1.8 that are not present
>> in
>> 1.7.x?
>>
>&g
On Tue, Jun 6, 2017 at 12:07 PM, Josh Elser 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 "safe" to
>> upgrade
y how it 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] http
t;.
>> (dev-1,
>> > dev-2*).
>> >
>> > The way that middle ground might work is: we clean up JIRA so that we
>> don't
>> > have to keep bumping issues which aren't being worked on (dev-2). Instead
>> > of starting patches at (dev-
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, maybe we ask nicely that s
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 Christopher wrote:
>>
&g
On Mon, Jun 5, 2017 at 2:12 PM, Christopher wrote:
> On Mon, Jun 5, 2017 at 1:18 PM Sean Busbey wrote:
>
>>
>> In my limited experience, when ASF projects don't reliably make
>> maintenance releases, enterprise customers turn to vendors to provide
>> a sour
On Mon, Jun 5, 2017 at 11:12 AM, Christopher wrote:
> On Mon, Jun 5, 2017 at 10:59 AM Sean Busbey wrote:
>
>> 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
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 sour
+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. Let me know if you have
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" wrote:
> I've always been un
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 Av
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 noticed that there were a
On Fri, Aug 26, 2016 at 11:58 AM, Christopher wrote:
> +1 for creating supported interfaces in our public API for these.
> Right now, I think all of these areas are suffering from bit rot/technical
> debt, and need to be cleaned up before (or in the process of) exposing them
> as public API.
>
C
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 here and
> speed things up
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 because I didn't see an em
-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
lar 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 support
, Christopher 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 get into a 2.0 will just happen at 3.0 instead.
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 Accumulo 1.8. It'd he
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 changed
> (I'm assuming
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 descr
nkins.
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
ow us 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 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
then Billie[2] adds
On Wed, Aug 3, 2016 at 5:17 PM, Christopher wrote:
> 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 mo
I think 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?
>
&g
do the referenced ITs still fail? IIRC, passing ITs is part of our
release criteria.
On Wed, Aug 3, 2016 at 1:52 PM, Michael Wall wrote:
> I just moved the last 2 tickets out of 1.8.0. Both tickets were for
> failing ITs. Seems like we are ready now for the release. Anyone disagree?
>
> I plan
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,
+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 thinking of in particular ar
racle-java8-installer shared/accepted-oracle-license-v1-1
select true | sudo /usr/bin/debconf-set-selections
RUN apt-get -q install --no-install-recommends -y oracle-java8-installer
Perhaps there is a similar Docker based option for your OS?
On Wed, Jul 20, 2016 at 2:32 PM, Sean Busbey wrote:
>
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 9:34 AM, Benson Margulies
>> wrote:
>>
>>>
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:
> That's just it... I don'
On Fri, Jul 8, 2016 at 3:40 PM, Christopher wrote:
> On Fri, Jul 8, 2016 at 11:20 AM Sean Busbey wrote:
>> Would we be bumping the Hadoop version while incrementing our minor
>> version number or our major version number?
>>
>>
>>
> Minor only, because it'
On Fri, Jul 8, 2016 at 10:19 AM, Sean Busbey wrote:
> On Thu, Jul 7, 2016 at 4:42 PM, Christopher wrote:
>> Ah, my mistake. I thought it was 2.7 and later. Well, then I guess the
>> question is whether we should bump to 2.8, then. I'm not a fan of the shim
>> layer.
On Thu, Jul 7, 2016 at 4:42 PM, Christopher wrote:
> Ah, my mistake. I thought it was 2.7 and later. Well, then I guess the
> question is whether we should bump to 2.8, then. I'm not a fan of the shim
> layer. I'd rather provide support for downstream packagers trying to
> backport for HTrace3, if
Sounds good. Please post a link here to the JIRA?
On Tue, Jul 5, 2016 at 4:58 PM, Christopher wrote:
> On Thu, Jun 30, 2016 at 5:43 PM Christopher wrote:
>
>> Hi all,
>>
>> I'd like to bring to your attention
>> https://issues.apache.org/jira/browse/ACCUMULO-4356, for discussion. Feel
>> free
On Fri, Jul 1, 2016 at 10:37 AM, Keith Turner wrote:
> On Fri, Jul 1, 2016 at 10:44 AM, Sean Busbey wrote:
>
>> Targeting for 2.0, including updates in the README, and having mean for
>> helping
>> the downstream user find the appropriate licensing information
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 cent
+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 wrote:
> Acc
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 all that
> much, but t
On Fri, Jun 17, 2016 at 2:53 PM, Sean Busbey 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 and ACCUMULO-4347
--
busbey
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" and all files
>> there
-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 but
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
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.
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 the recent changes in the API a
ade different than a 7->8 upgrade?
>
On Mon, May 2, 2016 at 10:31 AM, Keith Turner wrote:
> On Mon, May 2, 2016 at 1:54 AM, Sean Busbey wrote:
>
>> If we drop jdk7 support, I would strongly prefer a major version bump.
>>
>
>
> Whats the rationale for binding a bump
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
> 2.0.0-SNAPSHOT (and
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.
>>
>> http://abi-laboratory.pro/java/tracker/timeline/accumulo/
>>
>> The author of the Java API
been doing well since adopting
semver!
--
Sean Busbey
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 imagine this would be easy to bring over.
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 a
+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 site, no rendering or
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 certain
> that I could organ
1 - 100 of 904 matches
Mail list logo
