Awesome! Thanks for the intro Ed. I'm very curious if there's any
improvements or features we need to change in Accumulo to better
support erasure coding in HDFS (and especially if we can do so without
increasing our entanglement with Hadoop HDFS, specifically, as it is a
long-term goal of mine to
+1000 to what Josh said.
On Mon, Oct 21, 2019 at 10:11 AM Josh Elser wrote:
>
> Also, just in case you're feeling this way, any kind of contribution
> that you want to put together is helpful, welcome and appreciated.
>
> Please don't feel like you're unable to contribute because you can't get
>
Oh, one thing you could mention is how we've begun attempting to more
actively encourage participation among newcomers by inviting them to
subscribe and introduce themselves on the dev@ list.
On Tue, Oct 8, 2019 at 6:51 PM Christopher wrote:
>
> LGTM. Thanks, Mike!
>
> On Mon, Oct
LGTM. Thanks, Mike!
On Mon, Oct 7, 2019 at 9:46 PM Michael Wall wrote:
>
> The Apache Accumulo PMC decided to draft its quarterly board
> reports on the dev list. Here is a draft of our report which is due
> tomorrow, Wednesday, Oct 9, 1 week before the board meeting on
> Wednesday, Jul 16.
"Are you ready for #Hacktoberfest 2019? Support Open Source in October
and earn a limited edition T-shirt! @DigitalOcean @ThePracticalDev
https://hacktoberfest.digitalocean.com/ "
The above line is the canned promo tweet from the Hacktoberfest
website, but it summarizes the event better than I
Devs,
The Project Management Committee (PMC) for Apache Accumulo
has invited Holly Keebler to become a committer and we are pleased
to announce that she has accepted.
Holly started with contributions fixing some smaller issues, like
removing a premature "Master is down" message from the monitor
also?
* Figure out where the new DOAP file needs to be referenced for the
plugin to show up on projects.apache.org
On Wed, Aug 7, 2019 at 7:36 PM Christopher wrote:
>
> This vote passes with 3 binding +1s, and 1 non-binding +1.
>
> Thanks all!
>
> I'll begin release tasks for this
This vote passes with 3 binding +1s, and 1 non-binding +1.
Thanks all!
I'll begin release tasks for this shortly (it should be much simpler
than a full Accumulo release... there's much less to update on the
website).
On Wed, Aug 7, 2019 at 2:45 PM Christopher wrote:
>
> +1 from me.
Devs,
The Project Management Committee (PMC) for Apache Accumulo
has invited Adam Lerman to become a committer and we are pleased
to announce that he has accepted.
Adam has contributed several pull requests in the last year to enhance
features in the accumulo-shell and the VolumeChooser in 1.9
ied signatures
> > Was able to build Fluo against this RC
> >
> > On Sun, Aug 4, 2019 at 6:50 PM Christopher wrote:
> > >
> > > Accumulo Developers,
> > >
> > > Please consider the following candidate for Accumulo2 Maven Plugin 1.0.0.
>
It feels weird that more than 3 years worth of work can be summarized
in so few words, but I don't have any ideas for improving this. I
think it's fine if you want to send this out as-is.
On Mon, Aug 5, 2019 at 8:01 PM Mike Miller wrote:
>
> The Apache Accumulo project is pleased to announce the
On Mon, Aug 5, 2019 at 5:49 PM Keith Turner wrote:
>
> On Mon, Aug 5, 2019 at 10:46 AM Mike Miller wrote:
> >
> > What happens if nobody is interested in being a release manager for a
> > version?
> > What happens if the schedule is missed?
> > - Then there is no release. I would imagine if we
Accumulo Developers,
Please consider the following candidate for Accumulo2 Maven Plugin 1.0.0.
Git Commit:
c9ec8487898819edf3d70838abfe416077d27360
Branch:
1.0.0-rc1
If this vote passes, a gpg-signed tag will be created using:
git tag -f -m 'Accumulo2 Maven Plugin 1.0.0' -s
, Aug 1, 2019 at 8:40 PM Christopher wrote:
> It's getting late for me. I've completed some release tasks. I can finish
> the rest tomorrow:
>
> I completed:
> merged in approved rc2-next branch to 2.0 and merged forward
> created signed git tag for rel/2.0.0
> cleaned up rc branc
I'm in favor of this generally, but worry a bit about making release
schedule guarantees, due to the volunteer nature of the project Apache
projects in general.
What happens if nobody is interested in being a release manager for a version?
What happens if the schedule is missed?
Who handles
es, it may be desirable to create a tracking issue to replace
the JIRA issue, to identify and discuss the work, and then later
submit one or more pull requests referencing that issue. For
ACCUMULO-3455, a PR is probably sufficient.
Again, welcome to the project! We look forward to your contributions!
C
reporter.apache.org with release info
released the Maven staging repository for rc2
deleted old staging repositories
Most of what's left is website updates, which can be done tomorrow after
the mirrors sync up.
On Thu, Aug 1, 2019 at 8:12 PM Christopher wrote:
> This vote passes with 4 binding +1s (mmil
, and voted on this
release candidate. Your contributions are appreciated!
Thanks all,
Christopher
On Thu, Aug 1, 2019 at 7:58 PM Christopher wrote:
>
> +1 from me
>
> * I started up an instance in fluo-uno
> * I verified sigs and checksums
> * Javadoc and Source jars are presen
)
On Thu, Aug 1, 2019 at 3:20 PM Christopher wrote:
>
> I'm going to assume this was supposed to be "+1", as in "I am in favor
> of", rather than "+!", as in one of
> https://www.urbandictionary.com/define.php?term=%3A%21 :)
>
> O
fully ran unit tests
> Successfully ran sunny tests
> Built from source and installed via Fluo.
> Exercised standard operations via shell.
>
>
> -Original Message-
> From: Christopher
> Sent: Monday, July 29, 2019 4:10 PM
> To: accumulo-dev
> Subject: [V
That test is a bit non-deterministic. I looked into it awhile back. I
think it has something to do with how the executor service retains a
link to the thread-local parent span in Tracing (or rather, fails to
do so). To fix, we probably need a proper trace-aware thread service,
but that's probably
Found this extremely useful vim plugin for inspecting *.class files
with javap when opening them with vim:
https://github.com/udalov/javap-vim
Particularly useful when opening them inside a JAR:
1. vim
Accumulo Developers,
Please consider the following candidate for Apache Accumulo 2.0.0.
Changes since rc1: git log 4160067813..5a6481f7c1
Git Commit:
0b34e30c34b7c31ebb84ca6b3b686c1b3e7b19af
Branch:
2.0.0-rc2
If this vote passes, a gpg-signed tag will be created using:
git tag -f -m
t; > doesn't exist yet. This happens after I confirm with FS that the file
> > exists in HDFS. I will keep digging but it may have something to do with
> > the changes from the new Bulk import method and extra validation that was
> > added.
> >
> > On Mon, Jun 24, 20
This is great news.
https://github.blog/2019-06-25-assign-issues-to-issue-commenters/
and family.)
On Mon, Jun 24, 2019 at 6:38 PM Christopher wrote:
>
> -1 because of #1231 also.
>
> I will investigate https://github.com/apache/accumulo-maven-plugin/issues/4
>
> On Mon, Jun 24, 2019 at 9:00 AM Owens, Mark wrote:
> >
> > -1
> > Although my local
> > I tried building Fluo against this RC, but was unable to because of
> > > the following bug.
> > >
> > > https://github.com/apache/accumulo-maven-plugin/issues/4
> > >
> > > I found the following minor issues while testing.
> > >
&
o Java 8.
>
> [1]: https://github.com/apache/accumulo-testing/pull/81
>
> On Sun, Jun 9, 2019 at 10:33 PM Christopher wrote:
> >
> > THIS IS A TEST. No vote is necessary. As a test, I've prepared a test
> > build of 2.0.0. If this were a real vote, the rest of this e
Accumulo Developers,
Well, this is exciting, and a long time coming!
Please consider the following candidate for Apache Accumulo 2.0.0.
Git Commit:
a32ff67f1a455bc6cd21ef2854f8c1d1c0f7de98
Branch:
2.0.0-rc1
If this vote passes, a gpg-signed tag will be created using:
git tag -f -m
Typically, I set JAVA_HOME outside of the script, inside my ~/.bashrc,
but I think you can also set it in uno's conf/uno.conf file.
It looks like the main problem I see with Java 11, is the missing
javax.activation on the class path. It looks like Hadoop YARN might
need it, but we also need it
Is this using Java 11? Keith had mentioned that he had trouble using
Uno on Java 11, because YARN failed to start. What you're describing
sounds similar.
On Mon, Jun 17, 2019 at 4:12 PM Jeffrey Zeiberg wrote:
>
> This causes the error:
> zeiberg@dragonfly:~/github/fluo-uno/install/logs$ grep
until
2019-06? is released) in comment number 27:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=545293#c27
I hope this helps anybody using Java 11 with Eclipse.
Cheers,
Christopher
is remove
the (now useless) labels, and update the website/docs. I'll go ahead
and do that.
On Fri, Jun 14, 2019 at 2:04 PM Christopher wrote:
>
> The automation features are a bit limited. You can't specify rules
> based on labels. However, the whole point of this proposal is to
to comment here to indicate your readiness for
releasing 2.0.0.
Cheers,
Christopher
at the
> issue.
>
> Are new issues still created from the main issues page and then automatically
> placed onto project boards based upon labels?
>
>
> -Original Message-
> From: Christopher
> Sent: Friday, June 14, 2019 12:31 PM
> To: accumulo-dev
> Subject:
ood way to do that with GitHub Issues so I like
> this idea. The little bit that I have used the project boards was very
> pleasant.
>
> On Fri, Jun 14, 2019 at 12:30 PM Christopher wrote:
>
> > Accumulo Devs,
> >
> > I've started to play around with the GitHub
boards for tracking issues
for a release, I'm willing to do all the tedious work of converting
our labels over to project boards, and updating any relevant developer
docs.
Please consider this proposal. I think it's a big improvement to our
workflows, and I'm willing to do all the work.
Thanks for your consideration,
Christopher
THIS IS A TEST. No vote is necessary. As a test, I've prepared a test
build of 2.0.0. If this were a real vote, the rest of this email would
apply. Since this is merely a test, you do not need to respond. You
can, however (and are encouraged to do so), use the staged test
artifacts to perform any
The error is that it can't find header files for ruby. Depending on
your OS, you may be able to install them by installing a "ruby-devel"
package or similar.
On Fri, Jun 7, 2019 at 1:58 PM Jeffrey Zeiberg wrote:
>
> I am trying to start working on some of the website tasks and can't
> see to
I think since this never got a response after a year, I'm going to go
ahead and perform the proposed actions to archive these outdated
patches.
On Thu, Apr 12, 2018 at 5:35 PM Christopher wrote:
>
> Devs,
>
> Accumulo had 6 feature branches in our ASF-hosted git repository
Hi Devs,
The accumulo-wikisearch repository has several CVEs in its
dependencies found by GitHub, and (for those of us configured to
receive them) we are getting alerted by GitHub to fix these.
That repo is almost certainly very old, and unmaintained. I doubt it
even works. I'm inclined to
You might need to install snappy into your OS.
On Fedora: 'sudo dnf install snappy'
On RHEL/CentOS: 'sudo yum install snappy'
It's also possible that the version of Hadoop you're using doesn't
have its native libraries built, but it's hard to know more without
seeing more of the error message
to the 1.9 branch,
merge them into the 2.0 branch first, and then merge the 2.0 branch
into the master branch, so as to avoid regressions.
Thanks,
Christopher
Removing the observers requires rewriting the entire mechanism for
handling configuration changes that observers are currently handling.
It's not a simple replacement of the existing methods to an equivalent
set of methods. It would have to be rewritten to leverage ZooCache's
ability to track
The version required to build may change over time, but it is declared
in the pom.xml build configuration, and helpfully checked and enforced
by the maven-enforcer-plugin which will print a message and abort the
build if the requirements aren't met when you try to build. Currently,
1.8 is the
think Christopher closed that - the monitor is not expected to be a
> replacement for Prometheus / Graphina - but other's opinions may differ.
>
> -Original Message-
> From: d resnik [mailto:dresnik...@yahoo.com.INVALID]
> Sent: Tuesday, April 23, 2019 8:32 PM
> To:
t;
> On Mon, Apr 22, 2019 at 9:04 PM Christopher wrote:
>
> > Hi Accumulo Devs,
> >
> > As you may have noticed (or not) from the recent barrage of emails to
> > the notifications@ list, I'm trying to triage and close as many open
> > JIRA issues as possible, s
wishes to:
1. Triage issues that you have reported yourself, and close ones that
are unimportant or no longer applicable or
2. Find trivial/easy/fast issues to create a pull request to fix, so
we can close them as soon as they are fixed.
Any help would be appreciated.
Thanks,
Christopher
One pattern of creating keys might be to do so in a loop. Inside the
loop, you may wish to reuse these buffers... or you may wish to create
new buffers each you cycle.
If the first case, you'll want to ensure that Key copies the bytes. In
the second case, it's okay if Key just uses the bytes you
The primary purpose of this was to create an interface for
pretty-printing user's application code in the shell when we scan.
Some of the formatters (especially the DefaultFormatter) also ended up
getting reused internally in various places where we wanted to print a
key/value pair in a standard
on the PR.
> 2 - If any discussion is required before submitting code, create an issue
> in github and reference the Jira issue. Then we can close the issue in
> Jira and reference the github issue. No further discussion happens on Jira
> about the issue, it happens on the github issue and
d workflow.
On Wed, Apr 17, 2019 at 10:26 AM Michael Wall wrote:
>
> Hi Christopher,
>
> I'll disagree with you here. Going straight to a PR makes sense to me
> sometimes, but not always. What is missing in the straight to PR model is
> any discussion that would drive the
e the ticket in github and grab it.
>
> Don
>
> From: Michael Wall
> Sent: Wednesday, April 17, 2019 8:41 AM
> To: dev
> Subject: Re: new committer question
>
> [External Email]
>
> ------
r 11, 2019 at 9:46 PM Christopher wrote:
>
> > I wasn't able to get to it. Thanks for picking it up.
> >
> > The website now looks up-to-date, although I made some small polishing
> > changes and fixed some broken links in the examples.
> > I see Mike drafted the an
The Apache Accumulo project is pleased to announce the release
of Apache Accumulo 1.9.3!
Apache Accumulo 1.9.3 contains bug fixes for write-ahead logs,
compactions, and more. Users of all earlier versions are encouraged
to upgrade to this version. (See the release notes linked below for details.)
is to actually send the announcement to
user@a.a.o and announce@a.o (and Tweet it).
On Thu, Apr 11, 2019 at 4:19 PM Keith Turner wrote:
>
> On Wed, Apr 10, 2019 at 8:05 PM Christopher wrote:
> >
> > Completed release tasks:
> >
> > In git:
> > * Merge 1.9.3-rc3-next into
The 1.9.2 stuff sounds like we're only encouraging those users to
upgrade, when really, everybody should.
"Users of all previous versions are encouraged to upgrade to this
latest version."
For the second paragraph, we can just say:
"Users already planning an upgrade to 1.8 or 1.9, should upgrade
n dist-SVN:
* Archive 1.9.2 artifacts (after updating website)
Email:
* Draft and send announcement
On Wed, Apr 10, 2019 at 7:30 PM Christopher wrote:
>
> This vote passes with the following binding votes:
> +1 mmiller
> +1 edcoleman
> +1 mjwall
> +1 phrocker
> +1 jmark9
and report back here as I
complete the checklist.
Thanks again for voting!
--
Christopher
On Wed, Apr 10, 2019 at 7:23 PM Christopher wrote:
>
> +1 for me also.
>
> * Verified all ITs pass with Hadoop 2 and Hadoop 3 profiles
> * Verified source tarball matches git commit
> *
ully performed compaction as well.
> >
> > On Wed, Apr 10, 2019 at 12:52 PM Owens, Mark wrote:
> >
> > > +1
> > >
> > > Verified hashes
> > > Built from source
> > > Successfully ran maven sunny profile and unit tests.
> > > Used U
Try:
1. Place accumulo-1.9.3-bin.tar.gz into your uno downloads/ directory
2. Update conf/uno.conf to update the ACCUMULO_VERSION to 1.9.3
3. Update the ACCUMULO_HASH to
Accumulo Developers,
Please consider the following candidate for Apache Accumulo 1.9.3.
Git Commit:
a834aa8f36f1305b3d41abccb4eadc4f3b39302c
Branch:
1.9.3-rc3
If this vote passes, a gpg-signed tag will be created using:
git tag -f -m 'Apache Accumulo 1.9.3' -s rel/1.9.3 \
ge to
> https://accumulo.apache.org/contributor/verifying-release#foundation-level-requirements
> as well. I'll look for the template in code and make some PRs there and on
> the website after I give it some more thought.
>
> Mike
>
>
> On Tue, Apr 2, 2019 at 11:42 AM Chris
facts (a checksum is a
fixed characteristic, like file size; we vote on the contents of the
artifacts, not these traits); those other requirements for the mirrors
are not release vote requirements (which makes sense... we're voting
on the contents of the artifacts... not fixed, deterministic traits
I doubt there's any more leaks of this, but it's possible it leaks
transitively, via one of those dependencies in our "allow" ruleset for
apilyzer-maven-plugin:
https://github.com/apache/accumulo/blob/master/core/pom.xml#L191-L212
However, users can avoid issues with the older version by simply
This vote fails with {-1, -1, -1, -0, +1}.
I'll prep an RC3 once the issues identified in the thread are resolved.
--
On Wed, Mar 27, 2019 at 7:56 PM Christopher wrote:
>
> Accumulo Developers,
>
> Please consider the following candidate for Apache Accumulo 1.9.3.
>
> T
hange it in
the repo... or let me know and I'll change it.
On Mon, Apr 1, 2019 at 2:22 PM Josh Elser wrote:
>
> Again, like I included earlier:
>
> > (Append ".sha1", ".md5", or ".asc" to download the signature/hash for
> a given artifact.)
>
>
In what way?
On Mon, Apr 1, 2019 at 1:54 PM Josh Elser wrote:
>
> Your email template is wrong.
>
> On 4/1/19 1:33 PM, Christopher wrote:
> > Sorry, I don't understand what you mean by 'retelling of "checksums of
> > old"'.
> >
> > On Mon, Apr 1, 2
".sha1", ".md5", or ".asc" to download the signature/hash for
> a given artifact.)
>
> On 3/31/19 10:54 PM, Christopher wrote:
> > Mike,
> >
> > We already stopped using md5 and sha1 for the release artifacts on the
> > mirrors. I did this some t
#1065 inorder to get the verify M/R job to run.
> >
> > org.apache.accumulo.test.continuous.ContinuousVerify$Counts
> > REFERENCED=34417110819
> > UNREFERENCED=9097524
> >
> > On Wed, Mar 27, 2019 at 7:57 PM Christopher wrote:
> > >
>
This vote was superseded by the vote for RC2.
On Wed, Mar 27, 2019 at 10:45 AM Keith Turner wrote:
>
> On Wed, Mar 27, 2019 at 1:09 AM Christopher wrote:
> >
> > I'll also -1 for this. I'll put together an RC2 with the fix.
>
> Thanks Christopher. I successfully ran m
On Fri, Mar 29, 2019 at 1:42 PM Keith Turner wrote:
>
> On Thu, Mar 28, 2019 at 8:57 PM Christopher wrote:
> >
> > -1 due to https://github.com/apache/accumulo/issues/1064
>
> Do you know if this is a new bug since 1.9.2? Or does the same
> problem exist in 1.9.2, 1.
You could set up your iterators to communicate with each other when
initialized via the "source" parameter to the init() method.
However, because your iterators seem to be so dependent upon one
another, it might be better for you to implement this as a single
iterator. But, you can implement this
:
>
> > I did "sudo dnf downgrade gcc-c++" on Fedora 28, which it took me all the
> > way back to 8.0.1 and it still crashes. So it only works on 8.2.1?
> >
> > On Thu, Mar 28, 2019 at 5:59 PM Christopher wrote:
> >
> >> This problem appears to
m
>
> I have attached the stacktrace.
>
> On Wed, Mar 27, 2019 at 7:57 PM Christopher wrote:
>>
>> Accumulo Developers,
>>
>> Please consider the following candidate for Apache Accumulo 1.9.3.
>>
>> This supersedes RC1 and contains the following cha
lf
(or possibly your email client) messed with the mail headers for
threading.
On Thu, Mar 28, 2019 at 2:48 PM Christopher wrote:
>
> For many ITs, you can also add: '-Dtimeout.factor=2' (or 3, or whatever).
> This will increase the timeout threshold by the given multiplier,
> which can
For many ITs, you can also add: '-Dtimeout.factor=2' (or 3, or whatever).
This will increase the timeout threshold by the given multiplier,
which can be helpful if you run on slower hardware (or your AV is
interfering with performance, or whatever).
On Thu, Mar 28, 2019 at 2:30 PM Jeffrey
Accumulo Developers,
Please consider the following candidate for Apache Accumulo 1.9.3.
This supersedes RC1 and contains the following change:
https://github.com/apache/accumulo/pull/1057
Git Commit:
94f9782242a1f336e176c282f0f90063a21e361d
Branch:
1.9.3-rc2
If this vote passes, a
1057
> >
> > On Mon, Mar 25, 2019 at 7:41 PM Christopher wrote:
> > >
> > > Accumulo Developers,
> > >
> > > Please consider the following candidate for Apache Accumulo 1.9.3.
> > >
> > > Git Commit:
> > > d35a3f1e2be5
Accumulo Developers,
Please consider the following candidate for Apache Accumulo 1.9.3.
Git Commit:
d35a3f1e2be56779cf8b839a56988fdfcb34f600
Branch:
1.9.3-rc1
If this vote passes, a gpg-signed tag will be created using:
git tag -f -m 'Apache Accumulo 1.9.3' -s rel/1.9.3 \
It looks like we've got all the 1.9.3 outstanding issues closed (or
bumped), so I'm going to start working on a 1.9.3 RC1.
On Mon, Mar 11, 2019 at 12:59 PM Keith Turner wrote:
>
> +1
>
> On Fri, Mar 8, 2019 at 12:11 PM Mike Miller wrote:
> >
> > I was thinking it would be good to release 1.9.3
Are you using native maps?
Also, I'm in agreement with Josh that specific configuration flags may
not apply to everybody. The conf/accumulo-env.sh script is a
user-controllable file intended to be tweaked by system admins for
their environment. That said, it's possible some of these configs may
That sounds good to me. I really want to get 1.9.3 and 2.0.0 out soon.
On Fri, Mar 8, 2019 at 12:11 PM Mike Miller wrote:
>
> I was thinking it would be good to release 1.9.3 this month. The last 1.9
> release was July 2018.
>
> Then I was thinking we could release 2.0.0 in April. Alpha-1 was
Have you tried the "deleteRows" API?
http://static.javadoc.io/org.apache.accumulo/accumulo-core/1.9.2/org/apache/accumulo/core/client/admin/TableOperations.html#deleteRows-java.lang.String-org.apache.hadoop.io.Text-org.apache.hadoop.io.Text-
If I remember correctly, it will efficiently delete all
To be clear, we can't endorse any third party projects, commercial or
not, in order to remain independent.
We can, and do, provide a factual listings of related projects,
without endorsement. However, at this time, we've chosen to limit that
list to open source projects only.
On Wed, Jan 23, 2019
Resending with vote results with "result tag" in subject line:
This vote passes with 3 +1s, 1 +0s, and no other votes.
On Wed, Jan 30, 2019 at 8:12 PM Christopher wrote:
>
> Hi Accumulo devs,
>
> Sorry about the delay closing this vote. I had some personal/famil
ck if I see the same IT
> test failures, and hopefully be able to dig in and provide more useful
> information if the errors do not look transient.
>
> -Original Message-
>
> From: Christopher [mailto:ctubb...@apache.org]
> Sent: Thursday, January 17, 2019 8:09 PM
Sorry, my gpg key search seemed to match extra keys. The expected GPG
key is *ONLY*: 8CC4F8A2B29C2B040F2B835D6F0CDAE700B6899D
On Thu, Jan 17, 2019 at 8:09 PM Christopher wrote:
>
> Accumulo Developers,
>
> Please consider the following candidate for Apache Accumulo 2.0.0-alpha-2.
&g
Accumulo Developers,
Please consider the following candidate for Apache Accumulo 2.0.0-alpha-2.
Git Commit:
4d8405c0004c57b9c514c1f207461519cc58b3f7
Branch:
2.0.0-alpha-2-rc1
If this vote passes, a gpg-signed tag will be created using:
git tag -f -m 'Apache Accumulo 2.0.0-alpha-2'
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 of this alpha, we may want to do a beta (with
an API freeze?)... or just release 2.0.0 next. I wouldn't think we'd
want too many alphas.
They can be reused, if they haven't been closed (they are
AutoCloseable and should be closed when you're done with them). I
wouldn't recommend it, though. While most of the work is done in the
scanner's iterator() method, the close() method on the scanner API
implicitly associates the scanner's
I've seen similar problems with processes left behind on my own
Jenkins instance, but my solution is to periodically log in and nuke
the processes, and even occasionally reboot the instance. I don't
think these options are available to us on builds.apache.org, because
we don't have direct access
We did have a HipChat room, but we didn't advertise it well and nobody
really used it. With all that happened with HipChat being bought by
Atlassian and then sold off to Slack (or something like that), I'm not sure
where ASF Infra currently stands on providing chat as an ASF resource.
I have no
r
developers time is better spent not distracted by questions arising
from a shifting cultural landscape more focused on privacy.
> On 2018/11/02 20:54:59, Christopher wrote:
> > I think we should remove it. Given greater user concern over privacy
> > lately (with things like GDPR)
I think we should remove it. Given greater user concern over privacy
lately (with things like GDPR), and the fact that it we don't really
*need* the info (does anybody check the reports regularly?), I'd
prefer to just remove it. Infra was also discussing this:
s to the startup class loading, we also have the
per-table contexts in Accumulo, which allow separate class paths for
each table, which we'd still support in some way (though perhaps in
future, it could be implemented a bit better and configuring it would
be more explicit).
> Thanks,
>
> An
or a
beta, before 2.0 final... and if we did this for 2.0, I'd definitely
want another pre-release release first.
On Wed, Oct 24, 2018 at 3:10 PM Dave Marion wrote:
>
> I have talked with Christopher about the VFS class loader in general and I
> think he has a good approach. He can elaborat
Okay. Sounds good. I'll send it to user@ momentarily.
On Mon, Oct 15, 2018 at 2:24 PM Michael Wall wrote:
>
> Looks good to me Christopher, thanks for making a release in time for the
> summit. I agree with Mike about not sending to announce yet
>
> On Mon, Oct 15, 2018, 13:39 M
My intent was to send this email in a bit, but posted here first, just
in case anybody wants to look it over.
Not sure this alpha release should go to announce@apache, but maybe
just user@accumulo? Somebody could tweet also.
On Mon, Oct 15, 2018 at 1:15 PM Christopher wrote:
>
> The
The Apache Accumulo project is pleased to announce the release of
Apache Accumulo 2.0.0-alpha-1! This *alpha* release is a preview for
2.0.0 and contains numerous feature enhancements and API changes.
While this version is *not* recommended for production use, it is made
available for feedback,
301 - 400 of 1859 matches
Mail list logo
