Ditto on the below. I would love ASF-provided infra, but do not believe
it feasible for what we actually need. Do we need to perform some
diligence before going this route? Do we need to get an idea on actual
specs?
Christopher wrote:
Possibly. I did not pursue that route because I was pessim
Possibly. I did not pursue that route because I was pessimistic we could
get something powerful enough allocated to us.
On Thu, Jul 14, 2016 at 6:33 PM Sean Busbey 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
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'
That's just it... I don't want to encourage a dependence on it. It provides
some utility, yes, but I don't want to cross over into the area of it being
formally relied upon by the Accumulo PMC... because that raises the
concerns which my previous disclaimer email was supposed to alleviate.
On Thu,
But, at the same time, if we're going to be using this as a reliable
means for whether or not our tests are passing (which I would expect all
developers to be doing), it should be written down like we do for other
developer-related knowledge.
I don't see why we can't present it with the caveat
Given its "non-official" status (with respect to its affiliation with the
Foundation and PMC), I'd prefer not to formally list it on the website.
That might imply some long-term persistence and/or guarantees about
availability to the community, and I cannot offer such guarantees.
On Thu, Jul 14, 2
Bueno. Makes sense to me and avoids future issues with that lengthy
disclaimer you sent previously :)
Maybe have something on the website for contributors/new-devs to find
out about too?
Christopher wrote:
Well, it's already self-service, for those I've added. For anybody else, I
can add you
Ah, I see. So the KeywordExecutable stuff is required to call the no-arg
constructor to load classes, yet the one in the Shell is actually doing
work. (ServiceLoader, which KeywordExecutable uses, is best used when
instantiating lightweight factories.)
So, there are two options:
1. Make the no-
Well, it's already self-service, for those I've added. For anybody else, I
can add you if you send me your GitHub username. Then, you'll just have to
accept my invitation to the revelc organization on GitHub, and you'll be
able to log in and add yourself to the post-build notifications.
On Thu, Ju
I think I have isolated the problem and think this may be a bug. The
interference is happening when jline.console.ConsoleReader gets
instantiated in the constructor of org.apache.accumulo.shell.Shell. Even
though I am not starting the shell with bin/accumulo, it is still being
instantiated by the S
Yeah, that's a decent intermediate step. Getting an email is pretty much
the only thing that's going to force me to pay attention.
Making it self-service would be an even bigger plus, but I'm OK waiting
for "Christopher response time" :)
Michael Wall wrote:
I am good with that option Christo
I am good with that option Christopher.
On Thu, Jul 14, 2016 at 2:36 PM, Christopher wrote:
> The other option is that if people really want to subscribe to
> notifications, I can just add their email to the post-build notification
> email list directly. Since I'm willing to grant access to Accu
The other option is that if people really want to subscribe to
notifications, I can just add their email to the post-build notification
email list directly. Since I'm willing to grant access to Accumulo
developers already, they can also just add themselves by editing the
existing jobs.
RIght now,
Personally I am not in favor of automated things sending stuff to the dev
list. I like the dev just being discussion among humans.
On Thu, Jul 14, 2016 at 1:17 PM, Dylan Hutchison wrote:
> On the other hand, sending failed build notifications to the dev list
> motivates us to not break the test
On the other hand, sending failed build notifications to the dev list
motivates us to not break the tests and make the tests stable. I'll leave
it to your decision Chris, unless others have an opinion.
On Wed, Jul 13, 2016 at 8:54 PM, Christopher wrote:
> On Wed, Jul 13, 2016 at 11:02 PM Dylan
Github user milleruntime commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/122#discussion_r70811144
--- Diff:
core/src/test/java/org/apache/accumulo/core/iterators/user/FilterTest.java ---
@@ -234,20 +234,101 @@ public void test2a() throws IOException
Github user keith-turner commented on the issue:
https://github.com/apache/accumulo/pull/121
I cherry picked this back to 1.8 in my local fork. My intent is to play
around with this on a 10 node EC2 cluster. I will report back after I do that.
If anyone has any particular experimen
Sorry for the confusion, I was thinking that
org.apache.accumulo.shell.Shell gets instantiated when calling bin/accumulo
org.apache.accumulo.server.util.ChangeSecret. I think you are right about
the problem being with the classpath setup by the bin/accumulo script.
On Wed, Jul 13, 2016 at 6:33 PM,
18 matches
Mail list logo
