+1 on bringing this into Usergrid.
I suggest we place it at the top level of the directory structure, as a
peer of stack.
Regarding your question #3, I have been looking for the official ASF
foundation-wide policy, but as yet have only found a bulk contribution
policy for Apache UIMA:
https://uima.apache.org/contribution-policy.html
I think that sounds like the right policy. That means we need a signed SGA
for the contribution and ICLAs for any contributors before we can bring
this in.
- Dave
On Fri, Apr 11, 2014 at 12:28 AM, Rod Simpson <[email protected]> wrote:
> +1 This sounds awesome! Definitely a great addition to Usergrid.
>
> Rod
>
>
> --
> Rod Simpson
> @rockerston
> rodsimpson.com
>
> On April 10, 2014 at 8:44:35 PM, Todd Nine ([email protected]) wrote:
>
> IMHO I think
>
> 1) Yes we should.
>
> 2) If we're taking the approach that we release SDKs separately from
> the stack, then I think this can just be another tool that we release
> independently as well. This makes all the source available in one
> location, and easier for our users to grok and contribute.
>
>
>
> On Thu, Apr 10, 2014 at 9:48 PM, Alex Karasulu <[email protected]>
> wrote:
> > Hello Devs,
> >
> > <OT>
> >
> > I hope everyone is well and had a great time at Apache Con 2014 this
> week.
> >
> > </OT>
> >
> > I've been diverted from working on UG proper in an effort to be able to
> > thoroughly and easily stress test it in a production-like environment.
> This
> > includes testing methods, classes, and components in isolation as well
> the
> > entire system. I've been working on the code here: [0] with more info at
> > [1] and [2]. Initially I was hoping to use an existing toolkit to do this
> > (since frankly I did not wanted to deal with writing testing code)
> however
> > nothing really satisfied all our requirements:
> >
> > o test methods, classes and components in isolation as well as the entire
> > system,
> >
> > o be a able to leverage existing unit tests as stress tests with just an
> > annotation,
> >
> > o seamlessly integrate with our build and CI system
> >
> > o historically track the performance with metrics over the life of the
> > project
> >
> > o auto-[de]provision clusters needed (C* and ES) for the annotated tests
> > to hit
> >
> > Initially, I tried achieving this with JMeter and other such stress test
> > tools but it just didn't fly. So I thought I could whip up a small
> library
> > to get started and return back to the core persistence code. I did not
> > realize the time it would take. Honestly, I thought it would be throw
> away
> > code eventually and did not want to clutter our repository, while
> > generating needless traffic. Plus I needed some help and asked friends at
> > Safehaus who also had a similar need for their assistance and thankfully
> > they also helped out.
> >
> > So we've progressed considerably however IMHO I think this code belongs
> at
> > Apache alongside the UG code base which it was originally designed to
> > stress test. So now I have some questions:
> >
> > (1) Should we import this into our source code repository?
> >
> > (2) If yes to (1) then, where should it go? In a 'chop' folder as a peer
> of
> > the portal, sdk, and stack folders?
> >
> > (3) Do we need to get an ICLA on file for the guys who helped out while
> it
> > was hosted for the brief convenient time it was kept at the Safehaus?
> >
> > -----
> >
> > [0] - http://stash.safehaus.org/projects/CHOP/repos/main/browse
> >
> > [1] - http://jira.safehaus.org/browse/CHOP
> >
> > [2] - http://confluence.safehaus.org/display/CHOP/Home
> >
> >
> > --
> > Best Regards,
> > -- Alex
>
